Hello, world,

This write-up takes a deep dive into the process of developing a new product from the bare bones. I’ve been writing software for more than ten years and the reason for this post is to share the little knowledge I’ve acquired about building products all these years with the world. I discuss a few key things I wish I would have known when developing my first product.

In these years of SaaS/software development, I’ve built numerous projects from scratch, spent countless hours scavenging the web, browsing through technologies, libraries, frameworks to pick the right tech that would align with my requirements. I have wasted days, if not months, trying to implement stuff with a not-so-fitting technology. I have implemented stuff with tech having no support and community and have later cried for days into a pillow.

Picking the right technology stack as well as moving ahead with the right architectural design is crucial for the success of our product. There is no way around it. I think we all understand this pretty well. Once we get down to coding, there should be no looking back. We naturally can’t afford it.

Let’s step by step go through different phases of developing a software product, an app, SaaS, a startup, a project or whatever you want to call it.

Research

This is the most important part of the whole journey and shouldn’t be taken lightly. Before you even think of starting with the application design or picking the technology stack or anything, you should be thorough with your market research.

You should be crystal clear on things like why would a customer use your product as opposed to using your competitors’. What are your USPs?

What platform would suit best to launch your product? Mobile? Desktop? AR VR? Where do your target customers hang out? Assessing the existing competition (if there is any), how fast would you need to scale? What strategies do you have to out-market them? What additional/unique features should your product be loaded with to outclass every existing solution in the market?

I am not going to talk further about this. I know you got the point. There are a plethora of interesting articles already written on this. Just run a search on google for “market research for startups”

Here are a few that I recommend reading:

The story of Firefox OS
How to conduct a market research survey for your product idea
Think with Google is a pretty nice website that I came across to get the latest market insights from Google.

Moving on, let’s talk about the importance of having the architecture of our application right.

Product design

Importance of getting the application architecture right

The key element in successfully creating anything is getting the base right. Now whether it is constructing a building or making a pizza. If we don’t get the base right, we have to start over. Yeah! I know, but there is no other way around it.

Building a software product is no different. The architecture is its base and has to be carefully thought to avoid any major design changes and code refactoring at a later point in time.

Saying from experience, you don’t want to delve into re-designing stuff. It eats up your time like a black hole. It has the potential to push your shipping date further down the calendar by months, if not longer. And I won’t even bring up the wastage of engineering and financial resources which is caused due to this.

It also depends on what stage of the development process we hit an impasse due to the hasty decisions taken during the initial design phases. So, before we even touch the code, get our hands dirty, we have to make the underlying architecture right.

A look at the architecture of our app should bring a smile to everyone’s face. Although software development is an iterative and evolutionary process, we don’t always get things perfect on the first go. Still, this can’t be an excuse for not doing our homework.

An overview of the product development process

In the industry, consultants, architects, developers and product owners spend a lot of time studying and discussing business requirements. In software engineering jargon, this is known as “Requirement gathering and analysis”.

Once we are done with the business requirements, we sit down and brainstorm the use cases which we have to implement. This involves figuring out the corner cases as early as possible while fitting the Lego blocks together.

If you’re a fan of documentation, you might also want to write a high-level design document.

Once, we have an understanding of the business requirements, use cases, corner cases and everything. It’s time to start the research on picking the right technology stack to implement the use cases (more on this later in the article).

Proof Of Concept

After we pick the fitting tech stack, we start implementing a POC (Proof of Concept)

Why a POC?

A POC helps us get a closer, more hands-on view of the technology and the fundamental use case implementation. We get an insight into the pros and cons of the tech, performance or other technical limitations if any.

It helps with the learning curve if we’re working with completely new tech, also the non-technical people like the product owners, stakeholders, etc. have something concrete to play with and to base their further decisions on.

Now, this is only for an industry-scale product. If you are a solo indie developer or a small team, you can always skip the POC part and start with the main code.

So, we showcase the POC to the stakeholders and when everyone is satisfied, we finally get down to creating the main repo and our first dev branch on GitHub, BitBucket or any other similar code hosting service that you prefer.

Phew!!

So, by now you would have realized how important it is to get the architecture right the first time and the knowledge of web architecture to product developers.

If you want to master the fundamentals of web architecture starting right from zero, including the infrastructure on which our apps are deployed, distributed systems design and much more, check out the Zero to Software architect learning track that I’ve authored.

If you have a startup idea and ask yourself, how do I implement my app? What technologies do I use? Where do I start? This course will help you kickstart your entrepreneurial journey.

Picking the right technology

Be thorough with your use cases and system requirements

We should be crystal clear on what we are going to build. Things should not be hazy. We cannot pick the right tech if we are unclear on the requirements. Once we go hunting, we should be clear on what we are looking for.

For instance, when looking for a database, we should be clear on if we are going to store relational data or will it be document-oriented, semi-structured or with no structure at all.

Are we handling quite a large amount of data which is expected to grow exponentially? Or the data is expected to grow at a manageable pace upto a certain limit?

Will a monolithic architecture serve our requirements well or do we need to split our app into several different modules? Splitting the app into several modules using heterogeneous tech in services, helps us bail out on a particular technology in case things don’t work out.

See if what we already know fits the requirements

It’s always easier to build new applications with the tech we are well familiar with. This averts us from having to go through the steep learning curve that comes along with the new tech. Also, things are comparatively clearer when working with the tech, we are well familiar with. Being aware of the nitty-gritty, familiarity with the errors, exceptions and the knowledge to fix them helps us release the features at a quick pace.

Avoid running for shiny new tech until you really need them. Do not fall for the hype.

Imagine an exception thrown by a new tech that you haven’t seen before ever in your life and also cannot find the solution online. You are stranded. There is no one to help you, all you hear are crickets.

I’ve been there, done that. It’s frustrating, clicking through all the search result pages of Google. Finding nothing.

Does the tech we pick has an active community? How good are the documentation and support?

The technology we pick ought to have an active community. Check the involvement of the community on portals like GitHub, StackOverflow etc. The documentation should be smooth, and easy to comprehend.

Larger the community, the better. Having an active community means updated tools, libraries, frameworks and everything.

See if there is official support available for the tech. There should be some rescue available if we get stranded down the road. Right?

Is the tech being used by big guns in production?

If the tech we pick is being used by big guns in the industry, then this confirms it being battle-tested. It can be used in production without any worries. We can be certain that down the line we won’t face any inherent scalability, security or any other design-related issues with the technology, since, the codebase is continually patched with new updates, bugs and design fixes.

We can go through the engineering blogs of the companies to get more information on how they implement the tech.

Check the license. Is it open source and for commercial use?

Picking an open-source technology helps us write our own custom features in case the original solution does not have them. We do not have to rely on the creator of the tech for new features, etc.

Also, in terms of money, we don’t have to pay anyone any sort of fee to use the product. Open-source tech also has a larger community since the code is open to all, anyone can fork it, start writing new features or fix the existing known bugs.

Availability of skilled resources on the technology

Once our business starts gaining traction. We would need a hand to move at a quick pace and roll out new features within a stipulated time. It’s important that there are enough skilled resources available in the industry for the technology we pick.

For instance, it’s always easy to find a MySQL administrator or a Java developer as opposed to looking for a resource skilled in comparatively newer technology.

Now, folks!! is the time to start writing code 😊

Building an MVP (Minimum Viable Product)

When writing an MVP, be brutal about cutting out features. Throw out all the “good to have” features, get the skeleton ready, and implement the bare minimum, must-have, features first. Having the skeleton ready, something you could show to your team and friends won’t just brim you up with energy and motivation but will also enable you to launch your MVP before the deadline.

I know you would love to have all the beautiful features you have in your mind in the first release but please don’t get sucked up in that black hole. Always have a timeline in mind, live and die by it. Motivation and resources are limited.

Treat yourself as on a special forces mission, you have to get in there, do your thing and get out.

When you have an MVP ready, show it to the community. Get feedback. Reddit and IndieHackers are nice places for starting a discussion. You can also start a crowdfunding campaign for your product on Kickstarter or somewhere. If it’s an open-source thing, check out OpenCollective

Seeking out help!

For any kind of help related to code, there isn’t a better place than StackOverflow. Dev.to is an amazing portal for starting discussions with respect to building software.

I am Shivang, the author of this article. In my past life, I worked as a full-stack developer with the Hewlett Packard Enterprise Technical Solutions R&D team. You can read more about me here.

If you found the content helpful, check out the Zero to Software Architect learning track, a series of three courses I have written intending to educate you, step by step, on the domain of software architecture and distributed system design. The learning track takes you right from having no knowledge in it to making you a pro in designing large-scale distributed systems like YouTube, Netflix, Hotstar, and more.

If you found the content helpful, consider sharing it with your network for better reach. Here is my LinkedIn profile in case you want to say Hello 🙂