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

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. We built and checked as we went, weighing at each turn what to keep and what to throw away, and switching whenever something turned out not to fit. We look back on that trail in three chapters.

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, and 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, and the human becomes the bottleneck. No-code is built around the premise that a person operates the screens, which runs in the opposite direction from automating work or handing it to an AI.
• Configuration management and backups are weak, so the ordinary business of taking diffs, walking the history, and rolling back when something breaks is hard to do.
• The DB column names are a black box. Dataverse auto-generates its internal column names, which is fine when a human clicks through the UI, but a generative AI can neither know nor predict them. 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, once we actually used it, was 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, and for a small outfit that wanted to lean its operations onto AI, it is plainly too heavy. This isn't a matter of good or bad; the scale it assumes was simply different from ours.

It's hard to imagine now, but a year ago we were pasting source code into the web versions of ChatGPT and Claude, dropping the returned output back into VSCode, and managing it with git. Directing the AI and pulling its results together were both done by hand. ChatGPT and Claude weren't what they are now, either. 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 on its own, but the moment we tried to integrate it with what already existed it wouldn't line up, and it was day after day of rework and fixes.

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. We carried that double frustration into the next step.

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

Feeling the limits of no-code, and ready to let go of everything we'd built so far, we started searching for the foundation that would actually fit the AI era.

What we landed on was Supabase and Vercel. In July 2025, with a first commit titled "Supabase + Vercel," we cut a fresh repository and replaced the foundation with an AI-friendly, fully code-based platform in place of no-code.

Our reasons for Supabase were clear.

• Built on open-source PostgreSQL. It's mature, standard technology, so generative AI knows it well, and unlike the black-box column names we struggled with in Chapter 1, we hold the schema completely.
• The auth foundation is there from the start, so there is no need to build it from scratch.
• Vercel, built by the makers of Next.js, connects to Supabase in an officially supported way.

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

Even with the foundation set, the development itself was still a tightrope. Through this stretch we kept using Claude and Codex from 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 badly stuck piled up. The deadlock starts to move in the next chapter.

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

The turning point was when we started leaning the development itself onto AI. Before that, around October 2025, we came across the term "vibe coding" and began following indie developers working under the same banner. It didn't feel like an unusual move, more like being one person inside a larger current.

In February 2026 we added .claude/skills and began defining recurring work as skills. A skill is a procedure the AI reads every time: how to run a review (which angles, what to check), the release sequence (from commit to pull request to review to 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 depended on specific people became repeatable procedure.

In April we started running memory, a store of facts that persists across sessions holding project-specific coding conventions, the current state of what's done and what's left, and 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, and the drain of re-explaining everything from scratch drops sharply.

From here, the output changed visibly. The count of merged pull requests (PRs) makes it plain.

Table 1: Merged PRs by month

This jump didn't come from growing the team, and it didn't come 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 onto AI in turn: 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-pass review that pits a different AI system against the work, and backstopping all of it with CI and quality gates. Each of these is its own article, which we'll write up in turn. The "rework on repeat" from Chapter 1 changed shape too, and the AI charging off on its own assumptions grew far less frequent.

What grew wasn't only the raw intelligence of the LLM. The harness and surrounding tooling that drive it (skills, memory, MCP, plan/auto, the review and test machinery) evolved just as much. From February 2026 on, the pace of change around Claude was striking; with the same model, what you can get out of it shifts completely depending on the tools and the way you set it up. Supabase and Vercel were good choices, true, but the deciding factor wasn't any single library. 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 keep track of your company's externally visible attack surface.

See PentaTrail / CTEM