What is it about?

Today I'll share my approach to shipping an app idea. It's a compilation of my mistakes while working on my projects and what my freelance clients did.

I'll motivate you to start right where you are, and with skills you already have.

Future articles will cover marketing, fundraising, technical infrastructure, and other topics vital for the next steps.

Who is it for?

Software and application developers that have built dozens of applications for their clients, but not sure how to apply the experience collected along the way.

Perhaps you have started dreaming about launching your startup: your big thing, your rules, no more confusing tasks from your clients.

Maybe you even have your notes highlighting the ideas of what you can build. You are all set for your sailing.

By the way, if you want to know how I maximized time for my startups, you can read about it here.

Ok, so what's next?

What to build?

It may sound weird, but you may not need a planet-size idea or a game-changer app. Your creation doesn't even have to make the world a better place. That would be awesome though.

Sometimes all you need is just to help a group of people to get rid of their small itch.

It can be something as small and simple as making a good markdown editor, a user feedback platform, or a SaaS boilerplate.

Many apps of our days are overloaded with too many features and overwhelming UI. Sometimes all you need to outcompete your competitors is a high-quality product and a minimalistic approach.

Keeping things small will let you build a meaningful solution faster, reach your core audience easier and focus on what matters for MVP.

Note that when you start thinking about what "idea" to implement, you draw castles in the air - "Good to have" things, but unreal or useless.

In contrast, when you think about "what pain can I solve" - your focus is on a real issue, which hurts someone every day.

Ideally, you choose something that is your personal itch. Something that you understand, something that you can judge if it solves the issue or not.

When you work with your own pain - you don't need a group of testers. You are your best tester. You are part of your core audience. You can see the problem from the inside, instead of guessing about other people's pain.

But make sure that others have this itch too. Some market research should be considered. Maybe talk to potential customers, use survey questionnaires, etc to see if you share the same pains.

Ok, so you've chosen what to build (great if you did some research about competitors first) and you are ready for the next step, implementing your solution.

How to build it?

You need to think about the features of your solution and what building blocks they will require. From design to frontend, to backend, to architecture. Diving into each will easily go beyond this article's borders, so let's define the core principles.

1. Keep it as simple as possible in the beginning. That will let you move fast and change directions quickly during experimentation.
2. Stick with your stack. The technology stack doesn't matter much now. You'll alter it multiple times in the future. Just start with whatever stack you are familiar with the most.
3. It doesn’t have to be perfect. You'll most probably change the form of your solution multiple times before it stabilizes in the form that works. You can polish it when you have a ready solution available.

Let's look at each principle deeper.

Keep it simple stupid

You don't need complications at this stage. Things like linting, unit-/e2e- tests, and CI/CD automation are best practices. However, it’s best to keep them for a later stage.

Do not let yourself drown in setting up everything for production.

Remember that right now you just need to start. Once you have started and published something, you can go step by step to improve your dev workflow. Where it makes sense. When it makes sense.

Stick with your stack

To start you don't need to learn "yet another fancy JS framework" (although it can be tempting and be an incentive to start). Just take your favorite stack, the thing you are the most experienced with.

Sometimes you may get stuck thinking that your old bro [put your stack name here] is not good enough. Leave such thoughts away. You'll change it later. Maybe. Or maybe never.

In any case, your end users do not care which tech you use if your solution solves their issue.

In one of my future articles, I'll share a technical stack that I use for my projects.

Let it be not perfect

Perfectionism can block you from ever shipping.

Many of my clients spent years developing a fully functioning app with dozens of features without marketing and user feedback.

Unfortunately for some of them, this whole path was only to realize that the product is not demanded by the market. Hundreds of thousands of dollars were spent for nothing (well, maybe for experience?).

Only switch to high-quality code, advanced dev workflow, and multiple features when you get people's interest and some paying customers. But not earlier than it's needed.

You can have a big idea in your head. However, for the initial release - try to cut off everything that you won't need in the first month.

Some SaaS companies leave subscription/payment module implementation for post-release. They know that they'll have at least 30 days to implement it. And it's totally fine.

Publish it lean, make it grow muscles, and become polished over time.

When to build?

I have a rule - "Publish something today and improve it every day". When this article is live, my website is half done and lacks a lot of features. But

It's better to have a solid half than a shitty whole.

Don't worry much, no one remembers when Google was published. Make yourself a 24h hackathon, develop a single-feature MVP, and just

Thank you for reading!