8-Day SaaS MVP Challenge

Why small teams struggle more than they should.

I once heard a sentence that stayed with me longer than I expected:

“Amice, we know documentation is important BUT we don’t have time.”

….from one of my seniors.

It wasn’t said defensively.


It was said calmly, almost as a fact of life.

At the time, I had just joined a small-to-medium software company that had been running for years. On paper, it looked mature. In reality, I quickly noticed a pattern that many teams will find familiar.

Daily standups were long.

The same question came up every week: “Can it be done by this week?”

The answer was always yes.

The outcome rarely changed.

There were no clear design documents.

Most system knowledge lived in people’s heads.

Adding even a small feature felt risky — not because it was complex, but because no one was fully sure what it would break.

This echoed that senior's words again “Documentation is important BUT we don’t have time.”

So where did all the time go?

Not into building new things.

Into firefighting.

Production issues were patched one by one.

I remember one week, a client crashed the system with an exclamation mark (!). The team was under such pressure to "fix it now,"  They just added a quick line to block "!". It worked... until the next week, when a question mark (?) crashed it again.

Developers in the team were smart.
But the system forced them to choose "Speed" over "Solidity" every single time.

Fixes were layered on top of fixes.

The system kept working but became harder to reason about.

This isn’t an unusual story.
And it’s not about blaming any individual or team.

In fact, I have met many capable developers and product people stuck in similar environments. The real issue is structural:

when time is scarce, thinking is often the first thing that gets sacrificed.

And once thinking disappears, speed becomes an illusion — you move every day, but nothing truly progresses.

The question that kept bothering me

Instead of asking “Why don’t teams do things properly?”,

I start to think: 

• Do only large companies have the luxury of structure?
• When resources are limited — even down to one person — is chaos inevitable?

Because if the answer is YES, then most small teams are doomed from the start.

I didn’t want to argue this with opinions.

I wanted to test it with a real product, under real constraints.

The experiment: build properly, under constraint

After leaving that role, I picked up my own products again. One of them is a   B2B sales tool  I’m bootstrapping, called  Closmore .

Instead of rushing to “just ship something,” I set a constraint for myself:

One person. Eight working days. A usable MVP.

Not a demo.

Not a throwaway prototype.

Closmore workable MVP includes

A Chrome extension that talks to a real API backend,

with a mini CRM to review and manage the results.

A product built with:

1. Clear scope — knowing what not to build
2. Clear architecture — data flow before UI
3. Security-first thinking — no patching patches later
4. Focused execution and shipping out — no wasted work

Yes, I’m leveraging AI to code with me.

But speed doesn’t come from AI alone. It comes from a good plan. 

AI acts as my hands, but the Architecture is the brain. 

Without a plan, AI just helps you produce spaghetti code faster.

Why I’m sharing this publicly

Over the next days, I will be documenting this sprint in real-time.

Not as a tutorial.

Not as marketing fluff.
But as a transparent look at whether structure really beats chaos — even with extreme constraints.

What to expect in this series

• Why I refused to write a single line of code on Day 1.

• Why Monday.com didn’t work for most of us?

• How does the B2B Sales tools designed by Salespeople?

• How AI actually helped.

• And.....can I finish the MVP in 8-days?

  
  

#SaaS #BuildInPublic #MVP #ProductDevelopment #Closmore #AmiceDev