An Engineer’s guide to starting up — 0 to 3 Months

Hi! I’m Vinay and I’m the founder of Quadzig. Building a product and a business as a solo founder has come with a lot of learnings and I wanted to document these somewhere. This is as much a note to my future self if I decide to build another product as it is unsolicited advice to others.

The advice here is specifically aimed at developers/engineers who want to start up on their own but might not know how to get started. This is an opinionated guide to starting up and I have listed the things that have worked for me. I am sure there are other(and maybe better) ways to build a product as well. But, this is the path I took and it is working for me so far. A lot of the advice here focuses on avoiding common pitfalls as an engineer. With that disclaimer out of the way, let’s get started.

Step 1: Don’t build the product.

I know that sounds weird. But, your first step in the startup journey should not be building a full fledged product. Instead, test the waters with a small demo and a marketing page. In some cases, you might need to build a small proof of concept to check the feasibility which is fine. But, that is all it should be. Just a barebones proof of concept(no user registration, no fancy UI etc)

There are a few reasons why this is more valuable than starting to work on the product straight away.

1. When you start building a product, you spend considerable amount of time(months usually) and effort on the implementation and its draining to keep asking yourself “Will people use/pay for this?”. I have personally abandoned 2 to 3 ideas after spending 3 to 6 months building a product because I was not sure if people would pay for it and I could not push through the uncertainty.
2. When you build a marketing page, you will be forced to think about the value proposition of the product from a customer’s perspective. How can I get a customer excited? What pain points am I solving for my customers? What are the key features that my product will deliver on? What will the pricing look like? If you have a POC already, you can also create a polished demo video. Videos are much better at communicating ideas and it’s a safe way to showcase your product.
3. Building a marketing page is a few orders of magnitude easier than building an actual polished product/MVP.

If you have trouble building a marketing page, it usually means one of these 2 things.

1. Your idea is good but you suck at writing marketing content. The only advice I can give here is to go look at marketing pages of other early stage startups and try to imitate them.
2. You have not thought out your product idea well enough and you need to spend more time figuring out the value proposition.

Now that you have a marketing page, stick an email sign up form in there. It’s super easy to build this with a service like Mailchimp.

If you are still not convinced, here are a few examples.

• Doordash started as a marketing page — https://startupclass.samaltman.com/courses/lec08/
• Dunzo started as a WhatsApp group — https://startuptalky.com/dunzo-success-story/

Some tactical advice

1. Don’t spend a lot of time building a website from scratch. Either buy a template from ThemeForest or use a tool like Mailchimp to build the marketing page. The whole point is to spend as less effort as possible.
2. Put a chat bot on the page(but don’t make it annoying). Make it as easy as possible for people to get in touch with you. You can use the free tier of Userlike to get started.
3. Don’t spend a lot of time/money on finding the perfect domain name. The way I landed on “Quadzig” is by randomly uttering pronounceable gibberish and checking if the domain name is available. You just need a pronounceable name that sounds vaguely modern.
4. You don’t need a logo for the product yet.

Step 2: Do a Demo Launch

So, now that you have a fancy marketing page with a sign up form and maybe a video, it’s time to test the waters. Try finding a community where a considerable number of your prospective customers reside. This could be Reddit, Indie Hackers, Discord, Slack channel, Instagram, Twitter etc etc. Basically, any place that has a sizeable number of prospective customers/users who have the problem that you are trying to solve.

Most online communities are very forgiving and friendly to indie starters and will happily provide you with good feedback if they think that the product will solve a pain point they have. The happy path here would be that you get a lot of people excited and they sign up for the product.

Congratulations! You now have a mailing list! We talked about self doubt a bit earlier, this mailing list is the cure for that self doubt. When you are spending long gruelling hours working on the product alone, you no longer have to worry if people will use/pay for the product. You already know that at least some people are interested.

You can make the marketing page as elaborate as you want. You can add privacy policies, terms and conditions, a screenshot gallery, a video, a contact us page etc etc. It completely depends on what kind of product you are building. If you are building a B2C product, it’s probably enough to just build a simple page. If you are building an enterprise B2B product, people will look for a terms and conditions page and prefer that you are incorporated.. Fortunately, templates for these are also easy to find with services like Avodocs(but always get it reviewed by lawyers as well if you are doing B2B business).

Step 3: Build a MVP

You now have people excited about the product. Your next aim should be to deliver a working MVP as quickly as possible.

Avoid these mistakes

Here are some common pitfalls that I as an engineer fell into the first few times I tried building a product.

Over-engineering for Scale

Don’t build the product for 100,000 users. Building a product for 100,000 users is hard. As soon as you have that number in your head, you start thinking about a lot of evil things like optimizations, caching, CDNs, horizontal scaling, microservices(oh god please don’t do this).

No! What you want to build is crappy technical product that works for 10 to 15 simultaneous users. As soon as you start planning for those small numbers, a plethora of technical shortcuts open up and your speed of development increases drastically. You will no longer spend an afternoon fixing a N+1 query. Instead, you will spend that time building a cool new feature(or better yet, talking to customers).

As an engineer, you are wired to not accept sub-optimal technical solutions. Fight that instinct. Build shitty backends and beautiful frontends. If your next question is “Well, what if my product takes off and I am not able to scale?”. Well, first of all, that’s a good problem to have. Secondly, you would be surprised at how many scale problems can be solved by just throwing servers at the problem.

Here is the thought process: “Build a product that works for 100 users. When I get 1000 users, I will throw servers at the problem. When I get to 10,000 users, I will hire someone to scale and optimize the product for 10,000 users. When I get to 100,000 users, I will pay a team of engineers to rewrite the product in a month”.

Don’t build to learn

Don’t use technology you are unfamiliar with. I keep joking that if I only knew Fortran when I started building Quadzig, I would have built Quadzig in Fortran. While that’s a hyperbole, it’s also not far from the truth.

Do not fall into the trap of thinking “I will build this product using X technology that I want to learn. If the product does not succeed, then I would have learnt something new at least”.

Building a product is hard enough as is. Don’t set yourself up for failure by adding additional obstacles. Besides, the domain expertise and the breadth of experience you gain while building a product is much more valuable than a new language or framework you might pick up. You either build a product or a project. Decide on one and stick to it. Seriously, do not go for fancy new frameworks and languages because you want to learn it.

If you are unsure of a stack to use, here is a safe bet that you cannot go wrong with.

1. Ruby on Rails for backend with server side rendering
2. Bootstrap/CoreUI as frontend framework
3. Postgres/MySQL as database
4. Sidekiq for background processing(if you need one)

This stack will get you far in terms of productivity. Google any question related to these technologies and you will most likely find the answer you are looking for. If you are from a python background, there are equivalents like Django & Celery that are pretty mature.

Don’t start off with Microservices

You do not understand your product’s technical requirements well enough yet to plan for microservices. The overhead of managing multiple processes will kill your productivity. Aim to run as few services as possible(preferably one process for the application and one database).

Ideally, you deploy your MVP to a single EC2 Instance or a Digital Ocean droplet. Or just use a PaaS offering like Heroku and be done with it. If you are asking “But what if my product takes off and I am stuck with Heroku which everyone tells me does not scale?”, see the point on “Don’t build for 100,000 users.”

Don’t separate backend & frontend

Don’t separate backends and frontends by writing APIs and choosing a client side framework. You will spend a lot of time crafting the APIs and managing two separate codebases will bring down your productivity. Of course, if you are more productive building products this way, go for it. But don’t do this just for the reason that it’s a “best practice” or because every other company is building this way.

That’s a lot of bad engineering advice. But, they are also good “I want to build a MVP” advice. Just keep in mind that Security & Privacy are two areas which are non-negotiable. Avoid shortcuts in these two areas.

Here are some things that you should do

Aggressively negotiate the scope of the MVP with yourself.

It’s easy to lose track of features and start building all sorts of functionalities that you think are essential. Your aim should be to release a lean MVP as early as possible.

Here are some common features that you most likely do not need in your MVP.

1. SSO
2. Full fledged user management system
3. Granular billing(hourly/per minute etc)

Minimum Viable Product

I am going to stress the MVP concept again because it’s such a easy trap to fall into. Your goal should be to release a lean MVP and start customer conversations. This is important because you have to validate all of your assumptions about your product and customer base as early as possible. If you take 3 weeks to build a feature only to realize that no customer of yours is going to use it, that’s a lot of wasted productivity. Instead, release a MVP, get customers interested and start talking to them about what else they expect from your product or start pitching them more features before you build them.

Favour SaaS offerings

Favour other SaaS offerings for non differentiating features. Non differentiating features are those that are essential for your product but are not your core offerings. Examples are User authentication system, User management systems, Billing, Mailing etc. Don’t build any of these yourself. Pick a SaaS offering that already solves this and run with it. Here are some common offerings that you should use.

1. Authentication — Okta, Cognito(AWS)
2. Billing — Stripe Checkout. It’s just so good.
3. Mailing — AWS SES, Mailchimp
4. Feedback — Userback

Step 2.1 — Stop Building

I know this is clichéd, but I want to really stress this point. Even though I already had a bunch of customers interested in the product, it was still difficult for me to stop building and decide on a MVP launch date. Part of the reason was the fear of failure. “I have spent so much time and effort on this. What if no one uses it? Worse, what if it’s not received well?”.

With that thought rattling around in my head, I suddenly had a new idea for a feature that I absolutely had to build before launch. And once that feature was built, there was one more feature that popped up that was just as necessary. This can easily get out of hand and before long, you have spent 6 months on the MVP without talking to a single customer.

Do not do this. Either time-box or draw a hard line on the features that you will build and once you are done building them, stop building. As soon as your MVP is ready, your focus should be to talk to as many customers as possible and to sell the product.

Step 2.2 Build the Business Front

If you are building a technical product or a B2B enterprise product, just a simple marketing page will not cut it for a product launch. Your product is not just the server that’s running the application. It’s the combination of the technical implementation, documentation, the marketing pages, support channels, incorporated business etc. So, here are some todos before the final launch.

1. Set up some common emails for the company. The usual ones are support@yourcompany, security@yourcompany, yourname@yourcompany, sales@yourcompany. These 4 should be good enough to get started. I used Zoho’s free tier initially and it works well.
2. Set up a terms & conditions and privacy page. Use a service like Avodocs to generate these.
3. Set up a separate subdomain for documentation if you are building a technical product. Write as much documentation as you humanely can. I use Mkdocs to build Quadzig’s documentation and it works wonderfully.
4. Add a contact us page and stick your support@yourcompany email there.
5. If you are building a B2B product, you will need to incorporate. Incorporation is a painful process if you are doing it for the first time. Thankfully, there is Stripe Atlas and it takes away 90% of the pain and streamlines most of the process. Be aware that incorporation can take up to 2 months. So, if you have a release date in mind, start planning for this well in advance.
6. Set up some channels for feedback. We already talked about emails and chatbots. You can also set up tools like Userback that will let users provide contextual feedback while using your application.

Pricing your product

Your pricing can vary wildly depending on the nature of the product. But here are some general guidelines.

Do not charge based on what it costs

Do not charge based on what it costs you to keep the product up. As an example, if your product is a SaaS solution and it costs you 100 USD/month to run the business and you estimate that with this 100 USD, you can support 100 users, do not charge 2 USD/customer and consider it a 50% margin.

No! You should charge customers based on the value you deliver to them. This value of course is subjective. For example, by using my product, if a company is able to save 10 man hours every month for their software developers, then I would try to calculate my pricing based on the average hourly rate of said software developer. If my product improves a customer’s conversion rate, I would try to calculate my pricing based on what my customer charges their customer.

Do not price low

It’s tempting to think “If I charge high, no one will use my product”. Don’t do this. If the product delivers enough value, customers will pay for it. Besides, low price is sometimes associated with “cheap”. Acquiring customers is hard. If you charge high, you have to acquire a smaller number of customers to meet the same revenue targets.

Keep pricing simple

Don’t make pricing complicated on day 1. You should ideally be able to explain your product’s pricing in a couple of sentences. Anything more and you will turn away prospective customers. One of the first things customers do when they visit your SaaS product website is to look at the pricing section. If they are not able to figure out the pricing quickly, they will just leave. Aim to have nice round numbers based on a simple dimension like “Number of users”.

With all that said, pricing the product is really an art and it’s not something you will get right on day one. Just keep in mind that predictable & simple pricing is good.

Do not Incorporate unless absolutely necessary

If you are not building an Enterprise B2B product or if you don’t really care about pricing yet, you can also decide not to incorporate. This will save you a ton of time, effort and money. You can just stick a “Donate” or a “Support me on Patreon” button on your website to get an idea of whether customers will pay for the product. You can always decide to incorporate and start charging customers at a later date. There are a number of advantages to go this route.

1. With an unpaid product, there is no longer an obligation to do customer support diligently(though you should take as many opportunities as you can get to talk to customers). You don’t “owe” anything to anybody.
2. You avoid the painful process of incorporation
3. When you eventually start charging customers, you will have some data points on how much customers are willing to pay for your product.

Step 3: Release the Kraken! Or the MVP in this case.

So, you have worked hard over the past couple of months and you now have a working product that users can actually use and you have a billing page where people can pay. Great! It’s time to release now. Go back to the same community where you initially did a demo and make another post talking about the product. Get in touch with all those users who signed up from your demo.

If you are lucky, a large percentage of them will convert to paying customers. In this case, you have overcome the first major hurdle. Your plan should now be to aggressively iterate over the product through customer feedback.

If you are unlucky, and as is the case most of the time, you fail to convert any customers at all. This is fine. It takes a large amount of trust and value proposition to persuade a customer to start paying for a product. If you do not convert any customers, do not lose heart. Most startups go through months or years of having no revenue at all before finding the right product market fit. You can either choose to pivot(don’t do this too early) or you can choose to continue building the product while simultaneously trying to sell the product until the product reaches enough maturity that customers are willing to pay.

Some closing thoughts

While building a product is a lot of fun as an engineer, building a business might not be as much fun. This is something to keep in mind early on when you decide to start up. You will be spending at least 30% to 40% of time doing non technical work that you might not enjoy. Here are some examples tasks that I did not enjoy but still had to do because it’s part of building a business.

1. Talk to lawyers to make sure that the terms & conditions and privacy page were good enough(was pricey as well).
2. Fill out a 300 column excel sheet(don’t ask me why).
3. Write technical documentation.
4. Polishing the product — The last 10% of the work is polishing and it’s usually just grunt work trying to find that perfect UI/UX.
5. Write marketing content for the website
6. Fill out a fairly long application form & record a video pitching my product for YCombinator(did not get selected).
7. Promote Quadzig on public forums. I always felt a bit unclean(for a lack of a better word) doing this.

That said, there are also a lot of things that are non technical that I still enjoy

1. Talking to prospective customers is always fun. Extra fun if they have something nice to say about the product.
2. Planning the UI/UX for a particular feature from start to finish.

The point I am trying to make is that if you just build the product and do nothing else, it’s very unlikely that your product will take off. Sales and other non-technical work is an essential part of starting up and if you are averse to it, your chances of success drops. You should be ready to spend significant amount of time on non-technical tasks and these will only increase if you gain traction(which is good).

Starting up as a solo founder?

If you can, you should ideally find a co-founder early on. Ideally, the co-founder has the same(or better) level of excitement, commitment & domain expertise that you have. I will not go into details on why this is important. It has been covered well here

Full time or part time?

If you already have a full time job that you are already invested in, then it’s better to work part time on your product at least till you find some traction. But, if you are looking to switch jobs or if you are in between jobs, then it’s probably better to take a break and focus on your product full time for a few months at least. If it does not work out, you will have a new set of skills and at least one more line item on your resume for your next prospective employer.

Just keep in mind that if you are working part time on the product, you will spend long hours working in evenings and weekends. This can take a toll on your personal relationships if you don’t manage your time well.

Finances

It’s surprisingly cost effective to keep a software SaaS business running. I probably spent around a 100 USD/month for the first few months on the overall cost(which is already quite high). Most of these were subscriptions to other SaaS services like Mailchimp, Calendly etc.

For the infra cost, you can apply for credits on most major cloud platforms and they should provide you enough runway for at least a few months. AWS can provide you credits through their AWS Activate program and there are similar offerings for other cloud platforms.

Conclusion

And that brings me to the end of the blog post. If you find this post helpful or have any feedback, let me know on Twitter! And of course, while you are here, do checkout Quadzig. If you use AWS as your cloud provider, Quadzig can help you save time & money by giving you insights about your Cloud Infrastructure.