Startups

Debt in any form is a redflag. A lot of startups start with a vision but no clear direction. We code as per the final requirements to make sure it works once we reach the million userbase. There is nothing wrong however changes happen all the times and it’s hard to predict the final product resulting in discarding lot of code. Even worse, if the code stays, it affects the entire infrastructure badly. It’s like carrying diesel in your car trunk while you are running on petrol. You have a useful fuel but it’s not just right to drive your company.

Best practices include the following

– Build a modular software by dividing project into as small parts as possible

– Every part ( module ) is independent

– Ship the software as soon as possible

– Try to clean up code periodically. Ideally once a month for a day or every quarter. If you are not doing it at least twice a year, you will have to pay high interest on it

– If you can afford, hire a hacker whose job is to cut the code into 50% to perform the same amount of work.

In terms of code, lesser the better.

Every project have 3 pillars or attributes which sets the outcomes of the project. They are

1) Scope and/or Quality

2) Time and/or Schedule

3) Cost and/or Resource

Owner of the project can only control two attributes, while the third one comes it self.It is impossible to have three of them as per desire. It is also called “Triple Constrain” in project management terms, just if in case some one want to read further about it.

Once you have validated the idea, next step is to turn it into a business ( AKA Startup ).

Here is the formula to calculate the economics

A = Number of people with the same problem

B = Amount that each A is going to pay

C = A * B

D = Cost of providing B to A

If C>D, then there is a business. If not, there is not.

Now C wont be greater than D at all times, but in the long term, it should be.

Disclaimer : This is a very basic formula and is to calculate viability within minutes before deep diving into the detailed business modeling.

NOW.

There is no perfect product in the world. It improves over time. The longer you take to build, the lesser are the chances of it being successful. Ship the product as soon as possible. Get the early adopters, take feedback and build based on that. Do not be lost under your assumptions.

TL:DR

Instead of building something you want, ask people what they want.

Long

I am an Engineer my self and love building things. I have a way of thinking and I think that every one should think the way I think. This lead me to build a product that solves a problem in a specific way.

Here is where the mistake happens. I can start building things under the assumption that the world thinks like me. Other option is that I start asking the people if they would use my product ( Or pay for it ). Most difficult follow up question is to ask for upfront deposit for product. This is where the reality check happens. Earlier the question of cost comes in, better it is. People are generally nice enough NOT to refuse a free product.

So Summary, do ask the difficult question from the person you are building product for. If you do not, chances of success are rare.