7 Helpful Tips on Getting Most Out of Your MVP Within a Budget

No one wants to write a post-mortem for a brand new startup.

By going with an MVP first, you drastically increase your chances of success. It’s the best way to quickly develop a working product, build initial traction, and collect real user’s feedback for relatively cheap.

Cash burn is one of the three main reasons why startups fail. Here are essential tips to stay within a budget and timeline:

• Plan to sell your product. Marketing and sales might be more expensive than development.
• Choose only quick-to-implement versions of critical features for the MVP.
• You probably don’t need a mobile, web, and VR application for launch.
• Avoid over-engineering for billion users, build to scale.
• Focus on what’s critical for your product, and don’t make compromises there.
• Assemble the right team.
• Always analyze feedback and adjust.

Sell Your Product

It doesn’t matter if you only have a brilliant idea or an incredible product, focus on selling it. Monetization may make or break your concept, so it’s worth thinking through from the start. Getting people to know about your product isn’t free, so it should theoretically at least break even.

The number one mistake repeated over and over by technical founders is building the thing. It might have beautiful clean code, perfect architecture that scales like crazy, and a smooth user experience. It might even work and solve big problems for someone. The only problem is that no one except the team and maybe their friends know about its existence. Either it’s always “not ready yet,” or it’s already deployed on some domain, app store, or Google Play with zero sales and marketing effort. Unreachable by Google search, 0 reviews, and dozens of downloads by team members just for testing if it works. After years in the making, they don’t even know if that’s what somebody needs or wants. Those folks soon run of money for living and return to their jobs.

In the old days, with one-time-purchase software, things were relatively simple. You sold an app, and you got $100. The subscription model is better in the long run but much more complex with many key metrics to keep in mind. The most crucial difference is that the user’s lifetime value (LTV) consists of smaller subscription payments that are spread in time. Thus, the return on marketing and sales investment is lagging, and the sales process requires time and money to ramp up.

For example, the same app might be selling for $100 in one case or a $5/month subscription with two years of retention in another one. They invested $20k in a successful marketing campaign that brought 500 paying customers. In the first scenario, the app immediately made $50k in revenue to cover further development and marketing efforts. In the second scenario, they got only $2500 back in the first month. The subscription modes did build a relatively stable income stream, and total revenue might be more significant than with a one-time purchase, but it does require more time and investment. This example is over-simplified to explain the idea better. In reality, the subscription app will probably attract more users from the start, but some of them would churn much faster than the average retention period, and some will stay longer.

The same holds for the more expensive B2B subscription apps that attract new users by direct sales. Salespeople’s salaries are fixed expenses, while the income stream from businesses using the apps builds up in time. On every new salesperson, a startup would lose money first, reach equilibrium, return the invested funds, and finally make enough profits to scale the sales team.

Reaching profitability with the subscription model requires investments, and scaling it requires even more. You have to plan that in your budget.

Choose the Right Features for Your MVP

It’s wise to closely watch your competition and check what they are doing from time to time. You might notice that most of those products have gazillions of features. They must be necessary, right? Well, usually that’s not the case.

Let’s take a look at Google Search. They have regular search, snippets, voice input, integration with maps, business directory, product search, videos, images, image search, etc. Are those the core and most essential features of the search engine?

To answer that question, we must consider what exactly is a search engine. It’s an app that helps users find what they want. Based on that, Google Search might be niched down to separate search products with voice input as just another convenient input method. Google Maps, Google Business, Google Images, and many others are all standalone products integrated into the main Google Search.

Google Search is also extraordinarily generic and can find answers to many search queries. That’s why it’s so complicated under the hood. It has to understand the user intent and show relevant results based on that, and not just find pages that contain parts of the search query. Make the search app more specific, and you’ll get TripAdvisor for the best experience, Yelp for trustworthy businesses, GsmArena for a new smartphone, and so on. Many of those products aren’t considered search engines, but they help people find things they were looking for.

Great products often solve just one problem better than everyone else. Formulate the problem, confirm that your prospects have it, and it’s painful enough to pay for the solution. Start building MVP as the solution and add features as necessary.

You will most definitely need logins, some admin portal, usage analytics, feedback collection, etc. Don’t overcomplicate those. Simple logins can be implemented in a day, while complex roles with granular permissions, templates, change tracking, audits, multiple login methods, and more bells and whistles might take weeks. Keep it lean until you know it’s necessary to go fancy.

Now that you’ve got a list of essential features, it’s time to prioritize them and simplify it further. Just assign an “importance” rank like “not important,” “pretty important”, “critical” and a “difficulty” level “easy,” “normal,” “hard” to every one of them. Avoid “hard” and “not important” at all costs. Either figure out how to simplify those or skip them entirely. The development usually starts with the most important ones. Doing “easy” first works well for the MVP as it allows us to see the half-working product much sooner.

Most legacy products are bloated with features that no one uses. Someone thought it would be cool to add this. One user of a thousand wanted it, and the competitor had that. Features were added for years and never removed. Money was spent on their development. Who would pay even more to remove it? In best-case scenarios, they are hidden by some kind of advanced mode or huge settings dialogs, but often they clutter the whole UI.

Making something more straightforward is a competitive advantage that many forget. Simpler products are also much easier to evolve, with much faster and cheaper development.

Start With the Right Platform for Your Product

“We need an iOS app, Android app, responsive Web app, and it should run on smart TVs too” - those words for a client is like finding a goldmine for most software development companies. Huge team, everyone is busy, and the project goes according to the plan. Everyone celebrates launch after a year of hard work. Only a month after, it becomes clear that 80% of users and 95% of sessions are on mobile web, few people have downloaded the apps, and smart TVs haven’t even passed 0.1%. It turns out people check the weather mostly on their phones nowadays.

For most products, common sense is more than enough to decide the starting platform. It’s hard to use the BI app on a small smartphone screen; people use TVs for entertainment; not everyone has a VR set, etc. Based on the product nature and target audience, it’s relatively easy to pick an initial platform. Launching on many of them at the same time usually doesn’t make much sense as it would multiply the development costs, slow down the development, increase the overall complexity, and make it harder to pivot.

Successful products must stay nimble at times of uncertainty when significant changes based on initial user feedback are about to happen. Shipping the thing to the market as quickly as possible should be a top priority.

Once you know more about your users, their usage patterns, and what they are looking for in your product, scaling to additional platforms should be a breeze. Porting an existing product is much faster and cheaper than implementing everything in parallel. With the right technology stack, you can even partially avoid porting code by sharing a large portion of the initial codebase between multiple platforms. Javascript frameworks shine here. Many of them support native mobile development with a pretty similar experience to the web frontends. For clean and fast UIs, the mobile browser version may be more than enough too.

Marketing teams also love launches on new platforms. They got a vital info-fuel to generate pleasant spikes in user acquisition.

Avoid Over-Engineering but Keep Scalability in Mind

The majority of startups won’t be a new Twitter. Yet, many of them are engineered to handle much bigger loads than the initial Twitter version.

Unless your product is some kind of a soon-to-be-viral B2C game or app, you likely would never see steep jumps in the count of active users. It would be relatively steady, providing more than enough time to fix most scalability issues deliberately ignored during the initial launch before they become a problem.

For most applications, building a complex starship with dozens of microservices, databases, message queues, and complex deployment might not be the best solution from the start. It’s fun for the architect and DevOps. It might be necessary for an enterprise app to face tens of thousands of users on day one. It’s crucial for Aspecto that processes enormous traffic from every single client. It’s not the best for most B2B SaaS applications that do close to zero processing. Keep in mind that a single bare-metal server with some caching can handle more than ten thousand simple web sessions a day.

Under-engineering isn’t a good thing either. Hopefully, the day to scale past one physical server-equivalent will come soon, and your application must be ready. Building a monolith with complex queries to a relational database is a big no-no nowadays. Those are limited to scale only vertically, which becomes very expensive at some point before reaching its absolute maximum. Making those old-school applications highly available and redundant is also extremely hard, if not impossible, in many cases.

Ideal architecture lies somewhere in the middle. You should make it scalable, although not over-complicate things. Making core design changes will be extremely difficult after launch, so take some time to think about scalability from the start. Think microservices, build whatever solves the problem best.

Pick the right database that will cover your needs and scales well. Usually, something NoSQL would do the trick. Throwing Redis for caching should be easy, but do it after load testing and not from the start. ElasticSearch is easy to add, although many modern databases have quite decent built-in search capabilities that are more than enough for many projects. For transactional data and complex reports, you can include a reliable relational database to the mix.

Databases require some maintenance to function correctly. On low scales, where cost is not an issue, it’s often better to use a database as a service solution. The same goes for many other, not core parts of the product, like logging, error monitoring, push notifications, emails, etc.

If you plan to scale, you should start in the cloud. That would keep developers from thinking monolithically and relying on fast physical cores, vast amounts of ram, fast SSDs, and other hardware benefits.

Most popular cloud providers also have proprietary technologies that could significantly reduce the development time for some parts of the application. Do you have real reasons to go cloud agnostic?

• Cloud providers won’t go out of business anytime soon.
• None would raise prices drastically.
• You will be notified way ahead if they decide to discontinue the product you’ve relied on.
• Most likely, you will never switch cloud providers anyway.

The product doesn’t have to handle a billion users on the launch day. It doesn’t have to serve millions of users in the first week. It should provide enough time for you and your team to make ready for new loads while it increases.

Focus on User Experience

The core functionality that solves your users’ primary pain is the most important thing, and your MVP should do it perfectly from the start. Many products also share other important aspects that we will cover in this section.

First impressions matter a lot. Your product should look modern and be simple to get the job done.

Don’t try to make the design perfect. Modern design systems, like MaterialUI or Ant Design, are more than enough for most MVPs. With a wide variety of existing open-source components and frameworks, there should be a pretty unique reason to write all the visual components and CSS from scratch.

All popular design applications support importing building blocks from a popular framework and build with them. Making the design that follows the existing design system would greatly simplify the development as programmers will just throw components and worry less about styling them.

The design must be good. Some applications might benefit from making it perfect if that provides a strong competitive advantage. On the other hand, a clean and modern-looking one is a cost-effective option for the majority.

User experience is what often makes or breaks the application. All elements must be where the user expects them to be. It should be clear from the first glance what everything does, and it should do what the user desires and not something crazy. Don’t bloat the interface with rarely used elements and instead hide them somewhere or completely remove if they are no longer necessary.

Think about the features your users would use the most. Optimize them for simplicity and convenience. Try experimenting on mockups with different design options and input methods, like clicks, drags, swipes, etc.

Often, the people using the application the most before it goes to production would have their ideas and suggestions on the UI’s tricky parts. Listen to their opinion; usually, they have a point.

Try to conduct usability tests before launch and closely monitor the user behavior. Is the design intuitive? Do they get frustrated? Can they accomplish the tasks they want? Are they looking for something they can’t find?

The product might do the job, but users will churn before getting their “A-ha” moment if it looks outdated or hard to use. People love simplicity.

Assemble the Right Team

It’s hard to compete when you’re a one-man-army with limited time and knowledge. Assembling the right team is crucial for a startup’s success. You’ll need people with different skills, who are experts in their fields. So far, it’s obvious that someone should handle marketing, sales, UX design, and product development. You would probably need customer support too. During the early stages, founders often do most of that themselves.

Most of the working hours in software startups go on product development. To speed things up, you’ll need a team of developers, but keep in mind that the benefits you’ll get are not linear. Two developers won’t do the same amount of work twice as fast for the same money. Usually, the curve has pretty horrible diminishing returns. That can be partially avoided when developers are working on different parts of the project most of the time.

Every project has the right team size window. One developer would code something like Microsoft Office for years, while twenty developers would just split tasks in a simple todo-list app longer than one could program it from scratch.

Depending on the complexity, MVP’s right team is between 2 to 10 people, usually on the lower end. That way, few developers would be responsible for every part of the project, increasing the ”bus factor” while still having short communication and management overhead.

A weak team is one of the top 10 common reasons why startups fail. Everyone want’s a robust working product and not millions of spaghetti code lines. Going cheap here might turn out to be more expensive in the long run.

Every product should have a lead or a senior developer overseeing it. More manageable tasks can be accomplished by the cost-effective middle developers, while something even simpler borderline to routine can be a great learning experience for junior developers.

Some companies do hire only the best senior developers. It gets the job done, and often even slightly better, but not the most cost-effective approach. Writing markup, CSS, and simple logic is not that hard, and it’s a waste of time for a strong developer.

Freelancers vs. Company vs. In-House

There are three approaches to assembling your team. One way would be to go to the popular freelance marketplaces like UpWork and hire someone you’ve liked. Another method would be to trust the whole product to a specialized software development company. And finally, you can hire the right people locally. Of course, you can also combine these approaches or leverage different ones for different application parts. Let’s compare the pros and cons of each of them.

Freelancers

They are likely the cheapest option but require the most management effort from the client. Hourly rates for decent freelance developers range from $18 (Asia) to $100 (North America). The price doesn’t always correlate with quality, but developers with good ratings and mid-range prices are often a good bet. With an average rate of $40 for a senior developer from Eastern Europe, 160 hours of work would cost you $6400.

Pros of working with freelancers:

• It’s quite cheap
• They are usually reliable and incentivized to get good reviews
• They work on different projects thus have some experience in many areas
• Once you found an excellent expert, it’s easy to hire him for future tasks
• You have the flexibility to hire them monthly, hourly, or on a task basis
• The freelancers and the marketplace mostly handle the legal part, ask them to sign an NDA, and you’re set
• They already have their convenient workplace

Cons of working with freelancers:

• It’s not that easy to find a good one, so scaling the team is not that easy
• They might be overloaded with work, sick, or go on vacation anytime, and you can’t always rely on them
• You have to manage them one by one or trust someone to manage the team
• Every person has a limited skillset, so you will need multiple freelancers to cover the needs of your project
• Your team will work entirely remotely, thus will have some communication overhead and difficulties with following the same culture
• Evaluating freelancers requires technical expertise

From our experience, freelancers are suitable for small, not regular work. It might be, for example, an initial UX design, graphics, or other assets.

You can assign a small test task to a new freelancer to evaluate his skills and then decide if he’s the one for the main job.

Specialized Company

Those companies are a bit more expensive than freelancers. Hourly rates vary depending on the region with $40-$70 for a senior developer in Eastern Europe and $150-$250 in the United States. So 160 hours of work of a local US developer with a typical $170 hourly rate would cost $27200, while the same amount of work from, for example, a Ukrainian developer with $50/hour would cost $8000.

Pros of going with a specialized company:

• Companies from Asia, South America, and Eastern Europe aren’t too expensive
• They hire and choose the right people to get the job done
• Companies are about their reputation, portfolio, and reviews on platforms like Clutch
• An average company have a lot more expertise than a single person could ever have
• They follow processes to help and mentor middle and junior developers, including personal training, courses, and lectures
• It’s possible to upscale or downscale the team or gets one-time tasks done by a specialized person inside the company
• The company will fully manage your team and application development process
• Developers are working in the same office with zero overhead in-person communication
• The company can provide a temporary replacement when someone gets sick or goes on a vacation when you urgently need to get work done
• You’ll have legal agreements only with the company and pay only to the company
• The company provides everything developers might need to do their job
• When working with a local company, you can visit their office and collaborate with the team

Cons of working with a company:

• Most companies aren’t interested in a small project and will work only with some minimal budget that typically starts at $10k
• The company might need some time to set up a new team for your project
• Local companies in North America and the European Union might be a bit expensive
• You’ll still have mostly remote communication with your team
• It might be hard to pick a good company that also has expertise in your domain
• You have a risk of depending too much on your software partner
• Some company will push extra services or deliberately increase the complexity of the project

While companies are a bit more expensive than individual freelancers, you also get many benefits in return. They can reduce the costs by offloading some work to less experienced developers while maintaining the same code quality or offer specialized expertise for one-time tasks. It’s also possible to build a completely remote team that would work only on your project full-time.

In-House Development

In many parts of the world, it’s the most expensive option. You’ll have to hire the developers yourself, which can be challenging and costly. After hiring, you’ll have some employer responsibilities like paying taxes, submitting reports, and providing them a workplace. The demand for great developers is high, and big corporations can afford to pay them high salaries. An average senior developer hourly rate is around $60-$75, and you’ll pay for holidays, office, team buildings, and more.

Pros of having in-house developers:

• You can talk in-person any time
• You’ll get to know each other much better and build stronger relationships
• It’s easier to coordinate a local team
• Your developers would be more motivated for the product to succeed
• Full control of the hiring process, candidate flow, and interviews
• It’s possible to build a great culture within the company

Cons of in-house developers:

• Can be quite expensive
• In some areas of the world, hiring great developers might be pretty difficult
• You’ll have more legal responsibilities, HR, and office management
• It’s not easy to fire an employee in some countries
• Upscaling or downscaling the team becomes pretty hard
• You’ll have to keep the team busy, as you’ll be paying them monthly
• It’s impossible to hire a person for one-time tasks
• Employees get paid for vacations, holidays, and sick leaves
• You’re responsible for team management and motivation

In general, in-house developers are best suited for established companies with consistent, steady workloads. Startups are quite dynamic, requiring different people with different skill sets and varying workloads. While your employees would be more motivated than freelancers, paying a React developer for learning Node.js is not something you want.

Conclusion

Building an MVP is not easy and cheap. Your project success and cost depend on many factors.

When planning your budget, don’t forget that it’s not only about development. Marketing and sales are the lifeblood of any product and are also quite expensive. Then you’ll have recurring expenses on servers, support, and maintenance.

MVP development cost mostly depends on the complexity of the product itself, its features, and the engineers working on the application.

When developing features, focus on what’s crucial for the product and compromise on everything else. Try to avoid unimportant ones as they won’t benefit the final result but still require effort to implement. Focus on shipping your product to the market as soon as possible, as it will provide valuable feedback for future adjustments.

Assembling a great development team is as important as the product itself. Doing everything in-house is usually the most problematic and most expensive option but has many benefits, especially in the long run. A proven software development company that has required technical expertise and experience delivering similar products is more cost-effective, quicker, and convenient. Collaborate with freelancers if you already know someone you trust, you’re on a budget, or for one-time work.

The majority of MVPs in LeanyLabs go to production in 2-3 months with a single senior developer or a team of up to 3 developers and one part-time UX designer.

Feel free to book a meeting with our founders for more tips on your situation using the form below.

Good Luck with your MVP!