Fog Creek Software
Discussion Board

Sort of a business plan, but not a business plan

I have an idea. It's an application. I want to start developing it, but I keep on tripping all over myself. Sometimes I think I should start by the front-end. Then I change my mind and I think I should evolve the backend and make the front-end development a dependent of what comes out of it.

Other times I just give up, afraid of having a stroke of how confusing I am.

What I need is a textbook aproach on how to pick an idea you've had and start to build it. All the necessary steps, all that's needed.

Tuesday, August 3, 2004

I write everything from the back end forward, but I suppose it depends on your end goals.  Are you most concerned with form and usability, or are you most concerned with a tight, fast app that performs well?  I suppose you should make a pro/con list for each approach.

Tuesday, August 3, 2004

Don't overanalyze. Just do it.

John C.
Tuesday, August 3, 2004


Start with your customer!

Although, I think the fear to 'build first, sell later' is the same fear that prevents you from sharing your idea ... so many are afraid of actually sharing their idea for fear someone is 'waiting in the mist' with their IDEs fired up and ready to code.

Tuesday, August 3, 2004

Do you want to write an application?


Do you want to make a business selling an application?

If you want to write an application start programming.

If you want to make a business selling an application, do not start programming.  Start trying to identify who your customers will be, and start getting to know them, and the problems they face.  Make sure you really understand why the problems are problems.  Work out whether there is any way to influence them to buy your software.  Work out whether it would be risky for them to buy from such a small company.  Work out how they would typically procure products and whether your contacts at the company would even have a say in getting your product bought.  Work out what competition they would go to, to see whether your product stacks up.  Why would they go for yours?  Work out whether you could write it in an acceptable timeframe for them.

Once you've worked that out, then start thinking of writing it.  While you are writing it continually verify that people in your target market could actually use it to solve their problem.

Unfortunately you have to do the hard parts you don't want to acknowledge *before* firing up the IDE.

Tuesday, August 3, 2004

Start by doing the things that you have the least idea about how to do.

Tuesday, August 3, 2004

Konrad speaks some mega-truth there . . . the dot-com was all about "write once, sell many" ... many of us have our perverted entreprenurial motivations ingrained with taht mindset. It can work, but usually does not. When it does work, it requires more work . . .

Tuesday, August 3, 2004

+1 for Konrad speaking the truth.

Looking at it just from a coding perspective, I like writing the back end first, then writing the UI based on what evolved in the back end.  (Not that I've done this a lot, but hey, I'm still learning.  As evidenced by the fact that I ain't dead.)

However, you may not understand the problem domain well enough, in which case it may be appropriate to prototype/mock up a UI first.  Seeing how things get represented and fit together on the screen may give you a better idea of which objects you'll need in the back end, what behaviors they should have, etc.

Sam Livingston-Gray
Tuesday, August 3, 2004

Not that I have a ton of experience, but one thing I've picked up from playing on both the design and coding sides of the playground is that whichever one you're *not* focused on is the one that's easier to hack out.

For instance, if you're thinking about it from a coding perspective, you'll hem and haw over whether to start on the front or back (when it probably doesn't matter for v1 anyway), and just made ad hoc decisions about the design so you can get back to coding.

On the other hand, if you try and put yourself in "designer" mode, you'll hem and haw over big design decisions and just hack out the code so you can get back to design.

In your place, for all the reasons the other posters mentioned, I'd say the designer mindset is best. Once you've got a solid v1 (or .5 or whatever), you can switch back to coder mode and focus on churning it out. By that time, hopefully you'll have a better idea of where to spend your energy.

Tuesday, August 3, 2004

Note that when I say "you", I mean "me". I have no idea if this generalizes, but that's how it works for me.

Tuesday, August 3, 2004

      Smoky Bear statue: Who can help prevent forest fires?
      << Bart pushes the button marked "You" >>
      Smoky Bear statue: You pressed you, referring to me.  The correct answer is *you*.

Greg Hurlman
Tuesday, August 3, 2004

The front end is going to be largely responsible for people's response to your software.  Concentrate on architecting this as well as you can. I figure this is the tough bit.  While modelling the database can get complex I figure it's not as complex as designing an user-inteface that is clear and easy to use.

Tuesday, August 3, 2004

Well, surprise surprise.

I'm not selling. A true business plan does not come into play here.
It might have a database, but it's not a business app per se.

But I get it. Just start doing it. Wondering won't get me anywhere.

Tuesday, August 3, 2004

I like to design from the outside in, but code from the inside out.  You don't know the requirements for the inside's design until you have a pretty good idea of the shape of the outside.  But, it's harder to write automated tests for the outside than the inside, so you get farther faster if you code from the inside out (supported by tests).  When the inside is proven bug-free by a large enough set of unit tests, any bugs you encounter developing the UI are almost certainly bugs *in* the UI.  And, if you're not sure, you can easily add another test  to prove that the inside is bug-free, or alternatively that you have discovered a non-UI bug.

Phillip J. Eby
Tuesday, August 3, 2004

I'm gonna recommend the good-old "Getting Things Done" method of organizing your workload.

Think of the very next thing you can do to bring this to resolution & write it down.

I work off of a list most of the time and it makes me very productive. Just write down the things that need to be done - in chunks that actually can be done. I.e. not "program the front end" "program the back end" but "draw the front end on paper" "figure out the database schema" etc.

Then once you have this list, it should be easier for you to simply go down the list & see what appeals most to you or needs to be done soonest and start doing it.
Tuesday, August 3, 2004

Read 'The Inmates are Running the Asylum' by Alan Cooper

Wednesday, August 4, 2004

*  Recent Topics

*  Fog Creek Home