Simple app (fast development) or Powerful app (slow development)?

Discussions
#1

Of course it depends on the specifics, but I was wondering if anyone who has been through this before has any war stories or generic pearls of wisdom that might help me make a decision. I’m rather going round in circles…

I have read all the 37 signals ‘simplicity is best’ stuff and it’s very seductive. But frankly I (and everyone I have suggested Basecamp to) find their offerings over-simple and lowest common denominator. They don’t work for us.

My proposed app is a self-funded SAAS project management app for a niche in the construction industry which involves Hierarchical Bills of Materials (BOMs), Project Costing, Procurement Management, Change Orders etc. Target users are technically unsophisticated but they are frustrated with current offerings for their niche, which are over-simple and inflexible. More conventional and powerful project management systems don’t work for them either.

Here is the dilemma. Is it better to:

A. Implement a very simplified BOM methodology which does not strictly model the real world.
Pros:
App is initially easy to understand and use and perhaps more generic & flexible. Much quicker to develop.
Cons:
Inherently limited in functionality as the projects it is used to manage become bigger and more complex. Difficult to build in deep/powerful features later.

or

B. Implement the BOM strictly like the real world with all its inherent complexities.
Pros:
Much better foundation for long term growth in powerful/deep features. More robust data model can handle real world changes etc.
Cons:
Probably 5 times more work to build. More difficult for users to understand and learn.

Of course one could say ‘Build it simple to start with and then add complexity later.’ Perhaps I’m wrong, but I see these two paths as mutually exclusive because to achieve ‘A’ involves structural compromises which in order to achieve ‘B’ later are likely to make changes in data architecture (to a live system) a complex nightmare.

Any comments?

1 Like
#2

I’ve been in the same situation like you, build it simple and fast but hard to improve, or build it slowly but with a good foundation making it easy to add new features.

I chose the slow way, but I’m not sure if I did the right thing. I spent 3x times more than it should and now on the sales part, the users don’t care that your product is powerful “under the hood” and has a few more features, they seem to care more about solving their biggest issue they have on that matter, not even extra features.

Are you 100% that this product will work? If I had to do it again I would have started with a simple version, learn more about what users really need, get people to use your product and launch a new, better version based on what you learned.

1 Like
#3

I already built a simple desktop version which for reasons I wont bore you with, can’t be developed any more. So now I want to redo it for the web, The users seemed to be happy with it (as far as it went) but I feel that it could do so much more and be worth a lot more to them. I think if they could see how much money a more developed version could save them, they would probably agree. But they don’t know what can be done yet.

This is something I am funding myself, in my own time.

#4

If what you just said is true, then you do not have a choice but implement a powerful version.

At the same time, you probably cannot just dump the full power of your application onto the “unsophisticated” users’ heads.

You may try and make UI hide the complexity for first time users. Hide the more advanced sections and only open them when user requests advanced features. The underlying model would be the complex one but look simplish to the user; you just provide a set of reasonable defaults.

#5

Thanks.

The more I think about it the more I think you are dead right. Quick and dirty is not the way to go. Build it right but do a simplified user interface which can be expanded later.

#6

If there is a way to validate these assumptions then it’s always worth doing so I think. I’m constantly fighting and failing to beat the urge to build based on what I think users will want and almost always regret not validating first. I know all the lean startup talk can be tedious to hear, let alone practice, but there is some merit to it.

#7

My advice is to follow the “fast development” approach. Especially if you are “one man business” and you’re just starting. I did that years ago when starting my own software business and this was absolutely right choice.

Programming: implement features as fast as possible, and only implement what needed right now (do not build “cores” that are “extensible” and “future proof”). Implement in the simplest way possible. Yes, you will have so called “technical debt” that builds up while you develop this way. Yes, one time you will realize the debt is too big that it makes it hard (impossible) to maintain the software and add new features. But when this time comes, you should already have good understanding on what users need, and have enough money and experience to rewrite (refactor) the software the good way.

Same goes for the feature set. Implement only the vital features and some features that you feel important. No fine tuning, no premature optimization, no rare edge case handling or situation-specific (less than 1% users) features.

Fast approach is also good for the situation when the product didn’t work out. In this case, you have wasted less time.

3 Likes