The 3-Week MVP Process That Won Me the BuildSpace Grant

In my previous internship, which later became a job, I focused on building and prototyping internal tools, requiring me to quickly develop functional and solid software.

To enhance my workflow, I crafted my mindset and tech stack. Additionally, I sometimes had to design and build the MVP, expanding my scope.

The mindset I’m about to share helped me land a job after the internship, as well as landing 10s of freelancing clients, and most recently winning the “BuildSpace Season 5” grant for Modul.so.

Here are my actionable steps of how I do it:

1. Sort out my priorities
2. Requirements to sketching
3. Sketching to code (My tech stack)
4. Day-zero deployment

First: Sort out my priorities

MVPs’ primary purpose is demonstration and validation. This brings both good and bad news. The good news is that they only need to be functional enough to prove a business need or technicalities (in R&D). The bad news is limited resources, especially time, to build them.

So I have decided that with every piece of code I write, I optimize for this order of priorities:

1. Make it work and available
2. Make it performant (and pretty)
3. Make it secure and scalable

Note that I might adjust the priority based on the domain and use case. For instance, in building critical financial apps, prioritizing security is crucial due to their nature.

Second: Requirements to sketching

There are two scenarios:

Scenario 1: A designer on the team will take requirements, evaluate them, and provide detailed technical specs, a mockup, or high-fidelity design. Be proactive and give input if you think a design change can speed development. Most designers appreciate good input.

Scenario 2: You’ll receive MVP requirements in a PRD from your product manager or business analyst. Your goal is to understand the final product’s look and function, as you’re not a designer and the design will be iterated. Analyzing patterns in similar products can still yield good UI/UX (Discussed in the next section)

btw, I tool that love to use for quick sketching and documenting my ideas is Excalidraw. You might find it pretty handy.

Third: Sketching to code

If you are building your own thing or a part of a small team. You usually don’t have a dedicated UI designers team, and you can be asked to fill this role. When I’m in this situation, I try not to panic and do the following:

1. Go to Pinterest and search for something like “Budgeting App UI”
2. See what UI patterns are common between them
3. Go to any UI components library/directory for your tech stack (for example, 21st.dev for React/shadcn/Tailwind)
4. Fetch the components that align with the patterns you saw previously. Your goal is to mimic good design, not to be creative.

This strategy works every time because it uses validated design patterns and pre-made components to create similar UIs quickly.

Remember not to over-engineer, as your work may be iterated or rewritten anyway. That’s why I choose a tech stack I’m comfortable with to get from zero to product quickly.

For me, I use the following tech stack for most of my projects:

1. TypeScript: I love it and it’s a must if you are actually a serious JS/Web developer imo.
2. React and Next.js: This choice is totally based on preference and because I’m too comfortable using them as long as I don’t get hydration errors (joke).
3. Tailwind and Shadcn/ui: For how easy you can compose UI with it and the huge number of prebuilt components and templates that you can just copy/paste into your project and they just work with little to no configuration.
4. PostgreSQL: Of course I always think about the type of DB I should use depending on the project but most of the time a plain old SQL relational DB is all you need, however, PostgreSQL is nothing like “plain old”.
5. Drizzle or Prisma: Much love for both ORMs, and I use both of them in different projects and different settings.

Fourth: Day-zero deployment

Whenever starting a new project, I deploy it before working. This boosts confidence and allows immediate testing in the preview/production environment. Vercel simplifies the process by connecting your repo, setting environment variables, and, voilà, deploying with a single click.

Conclusion

This development process and tech stack is far from perfect by design (it didn’t include important aspects like testing, collaboration, etc.) because it assumes you are the sole contributor to the product. This process, however, shortens the distance between you and validating your idea from design to code. Most of the time, you will not be the only person working on the product, and sometimes you will be. My idea is to always be ready and deliver software no matter what.