How a Micro-SaaS Tech Stack Changed in a Single Year

From no-code to AI-native—one year of tech choices, traced through the commits we left behind

Over the past year, we rebuilt PentaTrail's tech stack from the ground up.

Not that there was ever a firm plan. The question was how to fit years of security experience to the fast-moving current of AI—and honestly, with no idea where it would lead, we felt our way forward, pulling at a thread in the dark. Requirements, design, and implementation stayed tangled together; at every turn we weighed what to keep and what to throw away, and each time something turned out not to fit, we switched. That trail is what's left in the commits and files. Here it is, in three chapters, plainly.

Chapter 1 — Microsoft and no-code, where it began (April–July 2025)

At first, we built on Microsoft's no-code foundation: Power Platform, Dataverse, and Azure.

There were genuine upsides. You design from the UI, screen-first. Because what you're building is visible, you get off the ground fast.

But the deeper we went, the more the structural limits showed.

• It assumes a human—so the human becomes the bottleneck. No-code is built around the premise that a person operates the screens. That runs in the opposite direction from automating work or handing it to an AI.
• Configuration management and backups are weak. Taking diffs, walking the history, rolling back when something breaks—those ordinary things are hard to do.
• The DB column names are a black box. Dataverse auto-generates its internal column names. That's fine when a human clicks through the UI, but when you try to have a generative AI write code, it can't know or predict those names. This was a fatal mismatch.
• Integration—including auth—is painful. Once you reach the point of wiring up external services and authentication systems, the friction only piles up inside the no-code box.

Azure taught us something too, once we actually used it: it's too fine-grained for a micro-SaaS. Both the granularity of its settings and its operational assumptions are built for at least a multi-person engineering team to develop and run. For a small outfit that wanted to lean its operations onto AI, it was plainly too heavy. Not a matter of good or bad—the scale it assumed was simply different from ours.

What captured the period best was how we actually worked. We'd paste source code into the web versions of ChatGPT and Claude, drop the returned output back into VSCode, and manage it with git—directing the AI and pulling its results together, all by hand.

And the ChatGPT and Claude of that time weren't what they are now. They couldn't fully grasp our intent, and the AI would build to a spec it had assumed on its own. The code looked fine in isolation, but the moment we tried to integrate it with what already existed, it wouldn't line up. Rework → fix → rework again, on repeat.

We wanted to lean on AI, but the AI was still immature, and the no-code foundation beneath us couldn't make use of it either—Chapter 1 was a season of that double frustration. That mismatch is what led to the next step.

Chapter 2 — A full migration to Supabase / Vercel (from July 2025)

Feeling the limits of no-code, and resolved to throw out everything built so far, we started searching: what foundation actually fits the AI era?

What we arrived at was Supabase and Vercel. In July 2025, with a first commit titled "Supabase + Vercel," we cut the repository anew—replacing the foundation, from no-code to an AI-friendly, fully code-based platform.

Our reasons for Supabase were clear.

• Built on open-source PostgreSQL. It's mature, standard technology, so generative AI knows it well. The exact opposite of the "black-box column names" we struggled with in Chapter 1—here, we hold the schema completely.
• Authentication built in. The auth foundation is there from the start; no need to build it from scratch.
• Official Vercel integration. Vercel, which pairs well with a Next.js front end, connects to Supabase in an officially supported way.

For payments, we went with the de facto standard, Stripe. Checkout, the customer portal, webhooks—all there, with plenty of proven Supabase integrations. No need to get clever; riding a proven default was the right call here.

Even with the foundation set, the development itself was still a tightrope. Through this period we kept using Claude and Codex via the CLI, but context broke whenever a session ended—and that weak continuity kept tripping us up. Sustaining consistent development was hard, and between the auth system and everything else, the days of getting deeply stuck piled up. This deadlock starts to move in the next chapter.

Chapter 3 — Going AI-native (from February 2026)

The real turning point was when we started leaning the development itself onto AI. The run-up to it: around October 2025, we came across the term "vibe coding," and began following indie developers working under the same banner. Nothing especially unusual about our move, we started to feel—just one participant in a larger current.

Then, in February 2026, we added .claude/skills and began defining recurring work as "skills." A skill is a procedure the AI reads every time. For example—how to run a review (which angles, what to check), the release sequence (from commit to pull request, review, and merge), the flow from pinning down a spec to a plan and on to implementation. The "knack" for how to proceed, which used to live only in our heads, got written out into procedures the AI could reproduce faithfully. Work that had been person-dependent turned into repeatable procedure.

In April we started running memory—a place where facts persist across sessions. What goes there: project-specific coding conventions, the state of what's done and what's left, and above all, past mistakes and their lessons. "Write it this way and it breaks here." "This assumption was wrong." Leave those lessons written down, and the next session's AI stops falling into the same traps. The drain of re-explaining everything from scratch dropped sharply, too.

From here, the output visibly changed. Measured by merged PRs—

Month	Merged PRs
Feb 2026	3
Mar	10
Apr	178
May	274
Jun	250 (partway through the month)

This jump came neither from growing the team nor from skills and memory alone. What worked was the maturation of the whole AI workflow. With skills and memory as the footing, each stage of development moved, in turn, onto an AI footing—MCP to let the AI touch the real environment, dropping a spec into a plan and letting it run semi-autonomously in auto mode, verifying AI-written code with TDD via pgTAP and vitest, running a two-stage review that pits a different AI system against it, and backstopping the whole with CI and quality gates (each its own article, to be written up in turn). The "rework on repeat" from Chapter 1 changed shape, too—the AI charging off on its own assumptions grew far less frequent.

And what grew wasn't the LLM's raw intelligence alone. The harness and surrounding tooling that drive it—skills, memory, MCP, plan/auto, the review and test machinery—evolved just as much. The Claude side especially, from February 2026 on, advanced at a staggering pace; with the same model, what you can get out of it changes completely depending on the tools and the staging you give it. Supabase was good, Vercel was fast—both true—but the deciding factor wasn't the individual library choice. It was that the way of working and the tooling behind it matured all at once. That's why the same people, in the same hours, could ship an order of magnitude more.

What this way of building produced

The micro-SaaS we've kept shipping while rebuilding it over this year is PentaTrail—a CTEM service that uses AI to continuously grasp your externally visible attack surface.

If you're curious, take a look at your own company's "externally visible attack surface."

See PentaTrail / CTEM