Build or Buy? Why Founders Are Coding Their Own Software.

I wanted a map in the top right corner of my community platform. For three years I had run that community on a well-regarded off-the-shelf product, and I was happy with it overall, but that one change was impossible. The vendor simply did not offer it. When I started building my own platform recently, I typed a short request into Claude asking for the map and a zoomed-out view. A minute later it had produced three mockups, and shortly after that the map was live.

That small moment says a lot about where software is heading. A member in our mastermind asked me to walk through how I decided to build instead of staying with the vendor, since it created a new job for me as the product manager of the thing I built. It is a fair challenge, and it deserves a careful answer, because build versus buy looks very different than it did two years ago.

What changed about the economics

I built the first version of this platform over about four days, mostly at my kitchen table while my four-year-old ran around. Over that stretch I averaged roughly 150 merges a day, and one day hit 316. We pushed around 500 separate rollouts through GitHub and Vercel. In total, the cost in AI credits was a couple of thousand dollars. A project like that would have cost around $200,000 two years ago and taken nine to twelve months to define, spec, build, and test. That is roughly a 99% cost reduction, and I am grateful for it.

A big part of why this works now is that the surrounding tools have matured. Platforms like Vercel and Supabase connect to each other cleanly, so a non-technical person who found this hard six to nine months ago can now get to a working product much faster. It still helps to have product instincts, but you no longer need a large engineering team to get started.

• The cost curve moved. A few thousand dollars in credits can produce what used to cost six figures.
• The time curve moved with it. Nine to twelve months of spec, build, and QA became days.
• The tooling connects. Hosting, databases, and deployment now work together with little setup.
• Product sense still matters. The person directing the AI has to know what good looks like.

Cheaper building changes the decision, but it does not remove the need for a clear rule about when to build.

The rule I use: if it is the business, build it

My rule is short. If a piece of software is core to your business, you have to make it. If it is your business, you really have to make it. As I put it to the group, if it is core to the future of your company, then you or someone on your team needs to build it, so that you can make it the best in the world.

The reason is control over speed. My community is the product I am selling, so the ability to change it quickly is the whole game. When I want a feature, I type it, review the result, and ship it. I do not file a request with a vendor, wait for a roadmap slot, or explain my use case to a support team. That ability to adjust things within minutes is worth more to me than the convenience of a managed product.

• Build what customers touch every day. The core experience is where small improvements compound.
• Build what differentiates you. If a competitor could buy the same tool, it cannot be your advantage.
• Buy what is generic. Payroll, email delivery, and similar utilities rarely deserve your attention.
• Ask what a vendor limits. If the vendor's roadmap holds back your product, that is a sign to build.

That rule works for me partly because of who I am. I have spent 24 years building software, and I love product management, so owning the roadmap is a pleasure rather than a burden. If you dislike that work, the calculation is different, and I will come back to that.

Your own product is a job, and you should want it

My member's concern was legitimate. Building your own platform makes you the product manager for it. You will spend time deciding priorities, reviewing changes, and fixing bugs. For me, product management is something I would do anyway, so the trade is easy. For a founder who has no interest in it, a build decision can quietly turn into a second full-time job.

It helps to be realistic about which kind of founder you are. I came into this as a product manager with UI and UX experience who is now becoming more technical through AI tools. In 24 years of building software, I never had a real GitHub history until this project, and in a few days I went from almost no contributions to hundreds. That is a strange outcome for someone with my background, and it only happened because the tools meet you where your skills already are.

• Check your appetite. If you enjoy shaping a product, owning the roadmap pays you back.
• Check your team. Someone must be responsible for quality, even if it is not you.
• Budget for the long run. The initial build is cheap, but the work of running it continues.
• Start with one real use case. Prove value with a narrow version before you replace your current tool.

Taking on a new product role also carries the risk that the maintenance load grows, which is the lesson another founder shared.

The maintenance warning from a founder who built too much

One founder on the call recently received a very large block of AI credits for his team, so he can build almost anything he can imagine. His own assessment was that his team made the mistake of building too much, and that he underestimated how much maintenance all software takes. In hindsight, he said, it was almost never worth building internal tools, and even parts of the core product were not worth it if a failure could break the whole company.

His rule of thumb was practical. If you are paying far too much for a simple tool, like a scheduling app, and you can recreate it and save five to ten thousand dollars a year, that is worth it. But he urged caution with critical infrastructure, where a bug or outage does real damage and the cost of fixing it is much higher than the license fee you were avoiding.

• Software has a tail. Every tool you build needs updates, monitoring, and someone who understands it.
• Savings must beat the upkeep. A saved license fee matters only if maintenance costs less.
• Protect critical systems. Keep billing, authentication, and data storage on proven platforms unless you have a strong reason.
• Prefer small and bounded builds. A simple, contained tool is much easier to maintain than a sprawling one.

I take that advice seriously. I built my platform with the knowledge that I will be its maintainer, and I keep the surrounding pieces, like hosting and databases, on proven services rather than reinventing them.

When you can build anything, choose one thing and go deep

The same founder asked a question I think many of us will face as building gets cheaper: with this much capacity, do you go wide and try everything, or go deep on one idea? His fear was building a lot of slop and wasting the opportunity.

My answer was to follow your passion and the market's feedback. Pick the idea you believe has the best chance of working and that you care about most, build a minimum version in four or five days, and get it in front of users. For an early-stage product, I like to ask a sharp question: how do I get one paying customer in the next ten days? If you can land one or two in that window, you sharpen your thinking quickly and learn whether the idea has legs.

• Choose by passion plus signal. Pick the idea you care about that also has real market pull.
• Ship a minimum version fast. Four or five days is enough to get a live demo in front of people.
• Target a first paying customer in ten days. It forces clarity about who the product is for.
• Expect to learn. The idea you start with may not be the one that works, and that is fine.

Cheap building makes it easy to start many things, but your time and focus are still limited, so discipline matters more than ever.

How I would decide this week

Make a list of the software your company depends on. For each item, ask whether it is core to your product, whether a vendor limits your ability to improve it, and whether someone on your team wants to own it. Build the ones that answer yes to all three, start small, and keep critical infrastructure on proven platforms. Everything else, keep buying.

The economics of building changed faster than most of us expected, and the founders who benefit are the ones who look at that change with a clear head. Build the things that make your business special, resist the urge to build everything else, and be ready for the long tail of maintenance that comes with every line of code.