← Posts
May 19, 2026·AI-Native SoftwareBuild vs. BuyGanttBasicProduct StrategyServerless SaaSCustom Software

Day 3

Stop buying tools that almost fit. Build the one that does.

Day 3

Don’t Buy GanttBasic. Build Your Own.

By Day 3, the experiment had a contradiction built into it.

I had spent two days testing whether AI could make it practical to build software around a specific workflow instead of buying the closest available tool. And now I was turning that software into something people could subscribe to.

That might sound like a strange argument for a product.

But it is actually the point.

If your workflow is specific enough, and the available tools force too many compromises, AI-assisted development may make it practical to build something much closer to what you actually need. In that sense, GanttBasic is not only a product. It is also an argument that more people should question the default assumption that the answer is always to buy software and adapt the workflow around it.

So yes, in the spirit of the experiment: don’t buy GanttBasic. Build your own.

Or at least ask whether you could.

That was the more interesting question by the third day. The question was no longer whether I could get a working app into a browser. By that point, GanttBasic could create projects, organize tasks, handle timelines, and work through dependency logic. It was usable enough to test and real enough to refine.

But working software is not the same thing as a product.

A working app would have been enough to show that the idea was possible. It would not have fully tested the bigger question. The hard part of building software has never been only the screen someone uses. It is everything around it that makes the product real.

So I kept going.

I added a defined brand identity and a custom domain. I built the system as a multi-tenant product with subscription tiers and plan limits. I added a paid Pro tier with Stripe integration, account management, and subscription management. I created SEO and AEO optimized “How to Plan” pages so the product had a path to being discovered. I added AI-assisted plan generation and refinement with token management. I set up a CI/CD pipeline. And because the system was built with SST and serverless architecture, it could stay secure, scalable, and cost-aware from the beginning.

None of that was necessary to make a demo.

But it was necessary to prove the point.

A prototype can show that an idea works. A product has to show that the idea can be packaged, found, trusted, paid for, maintained, and improved.

The other important detail is that this was literally three days of work.

Not three days of hand-coding every detail. By Day 2 and Day 3, much of the work had shifted into monitoring, course correction, and product judgment. At one point, I had six Claude Code agents working on different parts of the system at the same time.

One agent was refining the application experience. Another was working through billing. Another was improving the public pages. Another was focused on AI-assisted plan generation. Others were tightening infrastructure, deployment, and edge cases.

My job was not to type every line of code.

My job was to keep the system pointed in the right direction.

That meant reviewing decisions, catching assumptions, clarifying requirements, deciding what mattered, and stopping the work from drifting into complexity that did not serve the product. AI did not make the work disappear. It moved the work up a level.

That is where the contradiction became useful.

If building software gets easier, people will not pay for software just because it exists. That part is going to come under pressure. The value has to come from somewhere else.

For GanttBasic, the value is not “a Gantt chart on a screen.” The value is the thinking built into the workflow: the simplification, the defaults, the dependency-first planning model, the AI-assisted structure, the hosted infrastructure, and the fact that someone can use it immediately without designing, building, securing, maintaining, and improving their own system.

That brought the experiment back to where it started.

My wife was not looking for another project management platform. She simply wanted an easier way to create a Gantt chart.

That was the original need, and it remained the test all the way through the experiment: could a specific workflow become focused, usable, commercially viable software quickly enough to make the build-vs-buy question worth asking again?

For GanttBasic, the answer was yes.

Not because everyone needs this exact tool. And not because everyone should subscribe to another SaaS product.

The point is that software can now get much closer to the actual requirement, much faster, and at a much lower cost than before.

Sometimes that will mean buying a product that already fits.

Sometimes it may mean building your own.

GanttBasic is now live at https://www.ganttbasic.com.

Try it. Test it. If it fits the way you plan work, use it.

And if it does not, maybe that is the bigger point.

Build the version that does.