Your founder comes to you with the classic Minimum Viable Product (MVP) dilemma. We need to build quickly for speed to market, but make it maintainable so it can scale as we grow.

Ah, you want to have your cake and eat it! Brilliant.

Moving fast is one of the most advantageous tools in a startup's toolbox. MVPs primarily exist to help you learn, not just to launch, and by moving fast you can initiate the user feedback loop quicker and test your all-important product market fit.

But often quality is sacrificed for speed and many startups find themselves falling in to a "rewrite trap" as they need to scale and try to grow.

There are some steps we can take as CTOs to help. Let's explore them together!

Get moving whilst your still building!

Choose a Sensible Core Tech Stack

Choose technologies that are proven and boring to you over the latest cutting-edge can help mitigate the risk of building applications. Optimise for developer experience and team familiarity over theoretical performance gains. By using technologies you and your team are already experts in, you've immediately removed a risk.

There's also a wealth of developers building in proven, common technologies which makes hiring cheaper and faster, and there's tons of tutorials and assistance online for when you get stuck.

Here's some boring technologies I usually go to:

• Languages: Node.js/Python/Go (base this on your team's expertise)
• Database: PostgreSQL/DynamoDB
• Cloud: AWS
• Front End: React / React Native (Expo)

Build vs. Buy

I've previously written in detail about Buy vs. Build strategies - and this all stands true at the MVP stage too.

Why put yourself through the additional stress and pain of building non-core functionality from scratch when software like Stripe and Auth0 exist?

Build only what differentiates your product, and make your decisions based on the question: "Is this our competitive advantage?". If no, buy it.

Making It Non-Throwaway

By moving fast with existing knowledge and buying non-core functionality, you'll have far more time to invest in the things that are important for maintainable, foundational software. Following these three foundational rules can help set you on the right path to success:

1. Database Design

Your database is almost always the hardest foundation to change later. Spend time understanding how data should be structured and coming up with a good database design.

• Avoid duplicating data unnecessarily, but don't over-normalize either. Well-defined data relationships prevent data integrity issues that compound as you scale.
• Understand how your application is using data and index your actual query patterns as well as your primary keys. A missing index will cause performance issues at surprisingly low user counts.
• Keep consistent naming patterns for field names - e.g. use user_id not userId. Inconsistency creates bugs that waste debugging time.
• Use data types that make sense for your product. Some decisions I typically make:
  • Use UUID for IDs.
  • Use timestamp for dates.
  • Use integer for money to avoid floating point math.
  • Regardless of your choices, note down your decisions and keep them consistent.

2. API Design

Ensure you have clean API boundaries - mobile and web apps will depend on these contracts.

• Have consistent REST/GraphQL patterns such as ensuring resource names are always nouns and plural.
• Utilise the proper HTTP methods for the task the API is performing.
• Use the proper HTTP status codes.
• Valid input at the boundary - don't let it into your system.

3. Good Logging

Ensure you have comprehensive logging so that you give yourself the information to be able to debug production issues from day one.

• Ensure your logs are structured with consistent fields.
• Use request tracing so you can follow flows through your stack.
• Track feature usage so you understand what areas of your product are the most valuable.
• Consider if you want to implement feature flags or A/B testing tools to test hypotheses quickly.

Other Considerations

• Follow the YAGNI principle. You Ain't Gonna Need It. Considering YAGNI with each of your decisions will assist in avoiding over-engineered solutions and spending too long on "what if" scenarios.
• Be ok with intentional technical debt. Document why certain decisions and compromises were made and they will need to change as you grow. For example, maybe for speed you start with a monolith rather than microservices. Microservices add complexity, more deployments and complicate service communication and orchestration. Decisions can be logged and tracked using a simple ADR (Architectural Decision Record).
• Planning for 10x growth is fine. Be reasonable with the amount of architectural decisions you make around scale. Instead, design for observability and change. If something starts to scale poorly, you will be well equipped to spot the warning signs. Then when you do have to worry about 100x growth, it's likely you will be better equipped to make the right decisions for your product.
• Set up the basics for good coding practices. With minimal effort, it's possible to get linting and static analysis in to the code base from day one. Using a Github Actions workflow on pull requests can quickly assess code quality and ensure you are moving in the right direction.
• Think about testing strategy. Consider basic unit/integration tests for core user journeys such as sign up flow and payment processing. These can validate that your MVP's functionality remains consistent through a period of constant change.

Summary

Following the steps I've detailed here you can create a great MVP version of your app by learning quickly about your product market fit whilst still giving your product - and team - room to grow.

Well done, your founder is impressed! Enjoy the cake! 🍰