Once the presentations are done and the first positive feedback is in, you tell yourself: “That’s it, we’ve got the idea.”

Then a simple question arrives: but how do we actually build this?

Marty being my first entrepreneurial project, I hit a wall at that point. Going from a beautiful catalog of ambitious ideas to a functioning company is a massive gap.

It applies to everything: business development, marketing, SEO, tech.

In this article, we focus on the last one: the product and tech side.

How do you turn a pile of ideas into a SaaS?

As a technical founder, you quickly realize your own limits during this phase.

But a simple reality forces you past them: if you can’t do it, it won’t get done. And that can sink the whole project.

This article is a firsthand account of this critical phase and this complex role.

From the dream product to the buildable product

The project started with a classic mistake.

On the slides, Marty solved every problem in the sector: matchmaking, visibility, admin, time savings, for both B2B and B2C.

I understood at that point that in practice it would be impossible to build in a few months alone.

So I had to ask: what is truly essential? And what’s actually buildable?

For Marty, the identified demand was clear:

Give tradespeople quality visibility

A simple phrase that implies many technical challenges.

If like me you’d never worked on a “0 to 1” project before, you need to set up everything:

  • Interfaces
  • Authentication system
  • Data storage (application data, security, images, …)
  • AI systems
  • Payments
  • Matchmaking
  • Tracking
  • Infrastructure
  • Blog for SEO
  • Table schema
  • …

Key point: All of these tasks are standard in software. You’ll handle them fine. Just make sure to account for them in your idea of the buildable product.

The goal: Ship an MVP in 2-3 months to get real feedback as quickly as possible.

Choosing the stack and laying foundations

A classic situation in tech is to “quickly build a prototype to satisfy the business” with the idea that it will be rebuilt later.

Having lived through that several times, I kept in mind that once delivered, a product is considered functional, even if you’ve clearly stated it needs more work.

It’s a balance every tech person knows:

  • Move fast: because a product only has value if people use it
  • Lay solid foundations: maintainable and extensible by a single person in Marty’s context

Another responsibility of the technical founder is choosing architecture and tools. This choice will impact the product for years (capabilities, performance, technical debt, hiring, …).

For Marty, I decided to keep it simple, with proven tools.

The tech stack

Frontend:

  • TypeScript, React & Next.js: modern, well-understood stack

Backend:

  • Python with FastAPI: classic + existing expertise

Database:

  • PostgreSQL (PostGIS and PgVector): reliable + vector support

Infrastructure:

  • Docker + Cloud Run: simple, portable to K8s
  • GCP: simplicity + expertise
  • Vercel: simplifies frontend deployment

Advice: Simplify your tools. Your business solution will already be complex enough to build.

Building a tech product

A very rewarding phase was then thinking about a product that people would actually want, not just something functional.

That meant taking on additional roles:

The many roles of the technical founder

  • Product Manager: prioritize features, define specs
  • UX/UI Designer & Front dev: create coherent user flows adapted to the tradespeople world
  • Backend dev: implement product behavior (not just Data/ML APIs like I used to)
  • DevOps: deploy, monitor, secure
  • QA: test, debug, validate

Going from a Data Eng / MLOps role to a true full-stack role takes a lot of energy.

One day you’re optimizing an algorithm, the next you’re designing an interface, the day after that you’re configuring a production server.

It’s hard at first. Feeling lost is normal.

Remember: Keep the product goal in mind. Don’t get lost in technical rabbit holes. Yes, it’s a lot, but done in the right direction, it will work.

What I took from this second phase

Strengths

  • Going from concept to reality
  • Thinking long-term from day one
  • Having a complete view of the product

What I’d do differently

  • Better frame the business problem and the product response
  • Be less of a perfectionist
  • Ship faster (it took 5 months) to get real feedback sooner

Advice if you’re at this stage

  1. Clarify your core problem: accept cutting ideas in order to implement one perfectly

  2. Think long-term: avoid having to refactor within the year

  3. Only code the heart of your value: your value isn’t in auth or payments

  4. Ship fast: do everything you can to get real feedback quickly

What’s next in this series

In the next articles, I’ll cover:

  • “The technical impact of the business model”: How I implemented the tradespeople search engine to fit the SaaS model.

  • “AI and product: aligning user experience with response quality”: An article on my approach to choosing and integrating an AI solution into the product.

If these topics interest you, contact me by email or follow me on LinkedIn.

The goal of this series? Sharing concrete lessons to help other builders avoid the same mistakes. Every article will be actionable.