Where to start with your app idea
Andrii: Hello everyone, and welcome to the fourth episode of our podcast. Today, it's me, Andrii from Sommo, and…
Roman: ...me, Roman from Sommo.
Andrii: As you probably guessed, today we’ll be talking about how to take your product from an idea to a live release, and what steps to take afterward. We'll cover the key milestones and what you need to do to move forward.
As founders of a no-code/low-code studio, we’ll share our approach, because what else would we do in an episode like this, right? But seriously, we’ll explain why this approach is leaner and better for most cases. Roman, do you want to add anything or set some expectations before we dive in?
Roman: I think we should start with the most important question: if you have an app idea, where should you start?
Andrii: The first question is, what do you do when you have an idea? To proceed, you need to answer four key questions.
First, clearly define the problem you're solving.
Second, identify your target audience or ideal customer profile.
Third, figure out how you'll make money—what’s your business model? Will it be a subscription, transactional, percentage-based, or ad-supported model?
Lastly, decide on what exactly you’ll build, though this is often the least important because the solution will likely evolve as you better understand your problem, audience, and business model.
Roman: Yeah, and you also need to know how you'll attract your customers, which is key. What marketing channels will you use?
Andrii: Absolutely, that’s crucial and ties into your business model. You need to consider how much you'll spend on acquiring users and how much revenue they’ll generate after expenses. After answering these questions, it’s essential to validate them in the real world—not just in your head. First-time founders often fall into the trap of thinking validation means talking to friends or family. True validation involves speaking with dozens of potential users, conducting market research, and analyzing competitors to understand how you’ll differentiate.
It’s even better if you have industry experience, as it gives you insights into how things work and what your customers need.
But let’s move from theory to some real-life examples, yeah?
Roman: Yeah, a lot of theory! Let’s talk about some examples, like the ExitMania project we had recently at Sommo.
Andrii: Definitely. One of our clients, ExitMania, founded by Dervis from Germany, already had a successful business running live trivia games, escape games, and corporate events. It was a traditional service business, and he wanted to scale it digitally. He had the ideal setup—he knew his market, customers, and business model. The only thing missing was the digital solution, which is often the easiest part to develop when everything else is clear.
Roman: And who helped him with the digital solution?
Andrii: Guess who? The amazing team at Sommo! We helped turn his business idea into a successful digital product. We’ll dive into what we did specifically in the next parts of this episode.
Roman: Did he have a mobile app?
Andrii: Yes, he had both a mobile and a web app. We provided the complete package.
Budgeting your MVP
Andrii: Another important aspect is budgeting. We live in a capitalist world, so nothing is free, including launching your product. What’s a realistic budget range for getting started?
Roman: The budget can vary depending on the features, but from our experience, it typically starts around $15,000. That would cover a landing page, web application, and mobile app, plus design work. It’s a good starting point, though it can be higher for more complex MVPs.
Andrii: I totally agree. While $15,000 is a good starting point for most projects at Sommo, it’s wise to budget an extra 20-50% for further iterations since you rarely get it perfect on the first release. For example, with ExitMania, we spent just under $20,000 over three and a half months to take the idea to release.
Roman: That’s a good start, but let’s clarify what a good start actually means. Everyone talks about MVPs, but what exactly is an MVP, and what do you need to get it out the door?
Andrii: I once heard a friend joke that an MVP is just a product with a dark and light mode. Do you agree with that?
Roman: Haha, yeah, dark mode and light mode—the first feature you need, right?
Andrii: If you’re new to this joke, dark mode is definitely NOT what you should focus on in an MVP. Roman, can you explain what an MVP is and what should be included?
Roman: An MVP, or Minimum Viable Product, is the simplest version of your product that solves the core problem for your customer, without any unnecessary bells and whistles. It’s meant to get you started, earning money, and talking to your users. Too often, founders want to automate everything from the start, but you don’t need to do that initially. At the beginning, you can handle things manually, especially when user numbers are low. Automating too soon just inflates your budget and timeline unnecessarily.
Andrii: Absolutely, trying to automate everything will definitely increase your budget.
Roman: The key focus of an MVP should be communication with your customers. This could be through a support chat where you can engage directly with users, discuss their needs, and get feedback on features. It solves many problems because it’s human to human—people understand limitations, and sometimes, you can even make a sale right there through a genuine conversation.
Andrii: Great points, Roman. I completely agree. To summarize, it's about doing things that don't scale, a concept I believe Paul Graham from Y Combinator once highlighted. The advice still stands—don't try to automate everything at the start. Be hands-on and involved in the operations of your product.
For example, if you’re running a marketplace, like one of our clients, where you handle payments for therapy sessions, you don’t need to automate the payouts initially. You might have a few dozen users and therapists, and it's perfectly manageable to handle transactions manually. This not only saves money and keeps the project scope under control but also allows you to stay connected with your users and better understand their needs.
Sometimes, what you initially thought would be necessary—like specific types of bank transfers—might not even be what your users want. Keeping things manual allows you to pivot based on real feedback.
With ExitMania, for instance, the MVP was straightforward: users would select the games they wanted to play, pay through Stripe, receive a link via email, and then enter a unique code to start the game. It was simple but effective. Dervis, the founder, handled a lot of customer support manually, addressing issues and improving the app with each iteration based on real feedback.
Creating product requirements
Andrii: Once you have a clear idea of the core value you're delivering, or your MVP, the next step is to translate that idea into something others can understand.
Roman: Yeah, that’s usually a challenge…
Andrii: In life and in development! This process of translating your idea—your understanding of the business—into something actionable goes by various names. We call it product requirements, product specification, or software requirements specification (SRS). Essentially, it’s a document that outlines what you’re going to build.
Roman, can you explain what this document should include and how it’s created?
Roman: You don’t need to over-engineer your SRS. It should just outline the essential requirements of your product, describing the main features and the user journey at a high level. For example, you don’t need to specify every detail, like how you’ll validate an email or the exact password criteria—those are useful but not critical at the start.
If you have two types of users, like sellers and buyers, you just need to outline that they have different access portals and the key features each has. From there, describe how they interact through listings or other core functionalities.
We actually have a great SRS generator on our website, sommo.io/start, which can help you create a basic software requirements document for your product idea.
Andrii: That’s right! We created a page where you can input your product idea, and our AI—powered by OpenAI—will generate an SRS example for you. It’s a quick way to get a sense of what the document should look like. If you’re comfortable using tools like ChatGPT, you can generate it yourself, or find templates online.
But if you don’t have the time or expertise, you can always hire a contractor like us to do it for you. This is exactly what we did for Dervis from ExitMania. He was busy managing his existing business, so our project managers sat down with him, interviewed him about his vision, checked out competitors, and put together a detailed specification document.
Based on this document, any team—whether internal or external—can provide a more accurate quote and estimate for development. If you’re working with contractors like Sommo, having an SRS means you can get a clear quote or estimate of costs, and if the project is complex, it might involve a discovery stage for further refinement.
