Why I build for small businesses

There's a certain kind of problem I keep being drawn to.

It's not the distributed systems problem, or the billion-user scale problem. It's the "we're doing this in a spreadsheet and it's killing us" problem.

The cookie shop that loses 30% of orders because WhatsApp messages fall through the cracks. The accounting firm that spends two hours per client manually verifying crypto wallets. The vet clinic that has no web presence at all, so people don't know they're open at 3am.

These aren't glamorous problems. They don't make it onto Hacker News. But they're real, the feedback loop from "I built this" to "this saved me hours today" is measured in days, not quarters — and there's something deeply satisfying about that.

The long tail is underserved

Most software is built either for consumers at massive scale or for enterprises with procurement processes. The small business in the middle — the one with 3 to 30 people, real revenue, and zero engineering capacity — gets the leftovers.

They get SaaS tools that are 80% of what they need with 20% that's wrong for them. They get no-code tools that break the moment their workflow is slightly non-standard. They get agencies that build something, disappear, and leave them with code nobody can touch.

What they rarely get is a developer who actually understands their operation and builds something that fits it exactly.

Fast feedback changes how you build

When your client is a small business owner who uses what you build every day, the feedback is immediate and unambiguous. There's no product manager between you and the person with the problem. No sprint planning. No OKR alignment.

You ship something on Tuesday. By Thursday you know if it worked.

That compression of feedback changes how you make decisions. You stop optimizing for elegance and start optimizing for usefulness. You ask "does this save them time today?" before you ask anything else.

It compounds

The other thing about building for small businesses: every project teaches you something transferable.

The ordering system I built for a cookie shop taught me more about checkout UX than any case study. The crypto wallet verifier taught me on-chain proof patterns I now use in fintech work. The vet clinic site forced me to think seriously about local SEO and trust signals.

None of it is glamorous. All of it compounds.

That's why I keep coming back to it.

Thank you for reading!

Notes

For the past year, I've been following the content of Daniel Lima — "Brazil's first AI Agent & Micro-SaaS payments platform, built for and by the community", as he puts it — and founder of AbacatePay. The pitch is simple: fast, no-nonsense payments for the new generation of indie builders.

What makes his content worth your time is that he doesn't just talk about building in public — he does it. You get to watch a real fintech being built, shipped and sold in the open: the product decisions, the marketing experiments, the wins and the stuff that didn't work. For anyone trying to launch their own products, that kind of transparency is an absolute goldmine.

It also connects directly with everything I wrote above. AbacatePay exists because payments were built for big companies, and the small builder got the leftovers — the same long-tail problem, just on the fintech side. Seeing someone attack it head-on, with the community as both the audience and the customer, is a good reminder that "small" markets are often where the most interesting products start.

As someone who builds and ships my own products, his takes on marketing, AI and the mindset of shipping fast have genuinely changed how I think about my own work. If you're into startups, fintech, or just want to learn from someone who's in the trenches of Brazilian tech, check out his YouTube channel and AbacatePay.

Social Media

• LinkedIn: martin-fantinelli
• X/Twitter: @martinfantineli
• Instagram: @martinfantinelli