How To Build a Large Software Project Alone, From Scratch

Because all you need to get started is, well, you…

Time and again, we hear stories of great unicorns coming out of bright programmers’ brains.

Instagram founder, Kevin Systrom, was on vacation in Mexico with his girlfriend when he thought of Instagram’s famous X-Pro II filter. He coded it while being full-time employed with Nextstop.

Zuckerberg launched Facebook from his Harvard dorm. I haven’t heard if Harvard assignments are less demanding by any measure.

Did they achieve it through sheer passion and grit?

Absolutely.

And then, there is a way of how it’s done.

Step 1. Imagine It Being Used by Your Dumbest Customer

“Begin with the end in mind…”— Stephen Covey, 7 Habits of Highly Effective People

You must begin by imagining the end, then reverse-engineer your way. Your number one mistake was to start coding the innermost core to validate whether it could be done. That should have been your step two.

Your colleagues aren’t telling you the truth, but if you want that validation frequently in your career, maybe you are still a rookie. A veteran developer doesn’t succumb to every challenge that comes their way.

They choose them smartly. Because they know what they can do, and what they cannot, in a given amount of time.

In step 1, imagine it being used by your dumbest customer. It could be a consumer or a company. Even if it’s B2B, there may still be an end-customer for your product.

Imagine the user hopping between your product screens. As an extension of this step, create a mental model of entities, interactions, interrelated, and independent workflows.

Do not jump on deciding your scope though. The next step will decide how far you will go.

Step 2. Validate the Core Idea/Solution

This step is only necessary if you have technical doubts about the core problem’s solution.

If you are making a greeting-card maker website, make a front end where the user can enter a greeting message and their email. Add 10 basic, yet enticing animations. Include a recipient-email text box.

You don’t have to buy cloud hosting or email gateways to validate the whole thing. You don’t even have to write text box validations. Google your way to create the above screen. It’s very easy, and you will be happy to have accomplished something once you do it.

All you need to ensure is that you have identified the correct problem, and you intend to provide a minimum viable product that solves this problem. Do not worry about pricing at this stage. You can dream about your revenue figures though. It will bring you some good night’s sleep!

Step 3. Embrace the Beast

At this stage, your aircraft has taxied enough. Now is the time for take-off.

If you lose any more time making diagrams or discussing your idea with friends and family to make an impression, you are heading towards the premature death of your project.

Imagine them all making fun of your great startup that never really took off.

No matter how enticing it may feel, avoid documentation. It is, of course, necessary if you are working in a large team. It is also acceptable if you can’t progress without it.

By all means, though, do not consider it your real progress. I have seen many freelancers pile up READMEs and Google drawings during weekends.

At the end of six months, their Submit button brings 501.

How Would You Begin?

If you were a developer in an Agile team, your sole target is to meet the sprint goals. If so, in 80% of cases, you will do well by starting to develop the UI. Because it gives the entire team some validation and sense of progress.

However, your solo side-project doesn’t have to rely on Agile. You must not answer to anyone except yourself. You should try doing the hardest part first. I am talking about truly embracing the beast.

To make a kick-ass product, you would invariably need 1024 things besides solving the core problem. You need to be extremely aware of dependency management.

You must do user management because that’s the entry point for data. User data is and will be your most valuable commodity up until the day you decide to sell your venture to Facebook or Google.

With that comes networking. Remember handling payloads? You will have to store offline data and supply it via a mobile app/Dropbox integration, in case your most valuable consumer gets transferred to Greenland or the Congo.

And with that, how could you forget the cost that comes with data transfers? You must define the protocol that cost-effectively carries your payload between parties: HTTP, Websockets, TCP (Protobuffers), or something else?

Data security is the end-dependency in the chain once you have defined all other dependencies (unless your core offering is to solve a security problem).

How do you encrypt your data end-to-end? SHA? MD5? How will you implement public-private key handshake?

If you know these relevant terms, it is easy to search on GitHub or ask for opinions on forums. A good starting point is to search for any of those terms on Wikipedia and work your way up from there.

Learn about them, learn about their alternatives, and within little time you will be an expert judge in every technology you choose for your project.

Next: Implement them all. Without writing a single line of business logic, that is.

Make sure you read that right.

In a nutshell: Keep it as decoupled as possible from your business logic. Write with interfaces, write with abstract classes/structs. Make concrete test stubs to test them out.

Yes, to test this all with primate UI, you must write some test cases. Popular advice in software is about beginning with test cases, before writing a line of code.

TDD gives insights into your codebase that an expert reviewer cannot. You will realize its enormous value once you implement the next step.

Always remember: You could go wrong here in a thousand ways. But this step is much more than a lesson.

Work done here is never lost. It is reusable, because it is business logic agnostic. When you trash this project, remember that you could always reuse this beast to expedite all your future projects. Your time to develop will go down exponentially.

Step 4. Invoke Your Building Blocks

Having developed your core modules or microservices, you should now start implementing your core business features. It’s still a lot of work, but here you are making more choices with less implementation.

Would you ask for a log-in on the first use or would you allow five free, anonymous uses? In the case of no network/timeout, would you choose an error popup or vibrating text field?

How many configurable settings do you want to allow? Which UI theme would you choose for your entire app or website?

This is a scalable step. You could consider outsourcing this part to your colleague, friend, or co-founder. The questions outlined above can be answered for one screen or 100 screens.

Your models will follow the data items you expose. It would be a kind of copy-paste job for your entire workflow.

You could hire bright talent from college and make them your interns. It’s a great way of building connections and paying it forward. They will always be grateful to you and your project for the rest of their life.

Needless to say, if you did the previous step right, including the test case part, this step could be a breeze. If you didn’t, it would be your worst nightmare. And, you will abandon the ship forever.

Step 5. Deploy

Early software projects invariably needed DevOps. Today, the cloud has made scalability a breeze. You need to learn the terminology of your cloud provider, depending on the feature set you choose (storage, runtime, database, etc.).

Key players are AWS, Azure, and Google Cloud. Their pricing is great to decide if your project is economically viable in the long term.

For smaller projects, the cost could be anywhere around $100-$500 per month when you go with these solutions — I quote this figure from forums that talk about thousands of side-projects by indie developers.

If you feel that learning cloud is a burden, it’s a burden worth taking. Learning it once not only eases things up for your future projects. It also makes you a hot commodity in the job market.

Mark these words: As an indie software developer, you cannot and should not afford a cloud developer without external funding.

No-one in software can survive without a cloud solution, and you won’t go out of business for at least the next 10 years if you have a good grasp of cloud solutions.

Conclusion

This was about building a large software project as an indie developer. However, the steps will not be different even if you are working for an employer.

Your enthusiasm and passion will be the missing factors to some extent. Challenges and your intended approach to embracing them will remain the same.

Even if you fail, having done it once makes it worth telling your story to a crowd that’s eager to learn and passionate to implement.

As I just did.