The future of SaaS is tailored software

#ai#engineering#freelance#product#spec-driven

A few weeks ago I went to pick up a glass print from a friend’s workshop in Berlin.

Eric does custom printing — glass, wood, acrylic, business cards. Good work, small operation, knows all his customers by name. While I was there he mentioned he wanted to expand into NFC business cards. The kind where you tap your phone to a card and it opens a URL.

I said I could probably build that.

Three weeks later there’s a live product: a full ordering system, an admin panel for Eric, a customer portal where people can update their redirect URL, and a redirect that fires when someone taps the card. It’s running at nfc.glastrix.com.

I didn’t plan to become an NFC product developer. Here we are.

What we built

The product is simpler than it sounds but more complex than it looks.

A customer orders a card — they pick the material (PVC, bamboo, walnut, metal), upload a design, and specify where they want their NFC tap to redirect. Eric gets an email.

Then the printing happens, which is where things get specific. Eric runs a UV printer. The files it accepts have rules. White can’t be submitted as white — white ink on a UV printer needs to be printed first as an underlay, and for the machine to detect it, white elements have to be encoded as roughly 1% black, not pure white. If you upload a design with white text and the file says #ffffff, the printer ignores it and the text disappears. This is the kind of thing that only comes up when you talk to the person who actually operates the machine.

Beyond that: orders need to be batched into PDFs — all the card fronts for a given run in one file, all the backs in another, max 25 cards per batch. The admin panel generates those. Once the cards are printed, Eric scans a QR code to link each physical card to its order record, programs the NFC chip, and ships. When someone taps the card, it redirects.

The customer can change their redirect URL themselves at any time. No emailing Eric, no support ticket. Just log in and update it.

sequenceDiagram
    participant C as Customer
    participant W as Website
    participant E as Eric
    participant Card as NFC Card
    participant Edge as /c/BIZ-XXXX

    C->>W: Order (material, design, redirect URL)
    W->>E: Email notification
    E->>E: Print + program chip
    E->>W: Scan QR → activate card
    E->>C: Ship physical card
    C->>Card: Tap
    Card->>Edge: Edge redirect
    Edge->>C: LinkedIn / website / wherever

How it got built: specs first

Every feature started as a written spec.

Not a vague description — a proper document. What the user sees. What happens in the database. What the edge cases are. What counts as done. Only after the spec was written did I open Claude Code.

The workflow I use is one I’ve written about before: a kanban board with clear tasks for each agent session, regular check-ins to reorient, and a discipline of closing the loop before opening a new one. Each Eric conversation translated into a ticket. Each ticket became a spec. Each spec became a Claude session. The kanban kept it from becoming a pile of half-finished features.

Claude implemented. I reviewed, tested, deployed. When a feature worked, we moved on. When something broke, we went back to the spec, found what was underspecified, fixed it, and tried again.

The pattern that kept emerging: when we drifted from the spec mid-session — when I said “actually let’s just also add X while we’re in here” — things got messy. When we honored the spec, they worked.

The spec is also what made the 1% black thing buildable. Without that conversation with Eric, I would have built a design uploader that silently swallowed white elements and produced cards that looked fine on screen and wrong in print. The spec forced the question. Eric had the answer. Claude built the rule.

flowchart LR
    A["Customer conversation\n(Eric, real feedback)"] --> B["Write spec\n(what + why + edge cases)"]
    B --> C["Claude implements"]
    C --> D["Deploy to Vercel\n(~5 minutes)"]
    D --> E["Eric tests IRL\n(real NFC tap)"]
    E --> A

The product harness

The spec tells you what to build. You still need something that tells you whether it’s still working three weeks later.

Each feature got a golden — a concrete, verifiable statement of correct behavior. Not “the PDF export works” but “a bulk order with 5 cards produces a PDF with exactly 5 pages, each showing a different design” and “white pixels in a bamboo card design are replaced with 1% black before the file reaches the printer.” Each golden tied to a ticket. Each ticket to a conversation with Eric.

The harness has two layers. Smoke tests run automatically before every deploy — about fifty HTTP checks covering public routes, API validation, auth gates, and PDF shape rules. Then there are the manual goldens: a living checklist of behaviors that need a browser and human eyes to verify. Things like “drag the NFC icon to a free position — the ‘Custom position’ badge appears” or “scan the QR on page 1 of the bulk PDF — it goes to card 1’s destination, not card 2’s.”

There’s also a list of 14 documented risk areas — silent failure modes where nothing obviously breaks but something is quietly wrong. A bulk order that returns 200 but never writes to the database. A PDF where every page shows the same design because an async regen job failed. A printed card where the QR code routes the wrong person to the wrong URL. These are the failure modes that only emerge from real-world use, and the only way to catch them is to have thought carefully about what “wrong” looks like before it happens.

The interesting thing about a harness like this is that it’s also tailored. The goldens encode knowledge that would otherwise live only in Eric’s head — the UV printer’s file requirements, the batch PDF workflow, the edge cases in NFC programming. A generic NFC card platform wouldn’t have these rules. This one does because Eric was in the room.

Direct customer contact is everything

Eric wasn’t a client in the traditional sense. He was in the loop — constantly.

The admin card activation flow changed three times. Not because I changed my mind, but because Eric sent voice notes describing what it felt like to actually use it. “When I scan the QR it takes me to the URL but I haven’t confirmed it yet — can I see the card details first?” That’s a five-minute conversation that produces a better product. No Figma prototype, no user research session, no sprint ceremony.

The hotel variant — a whole separate product tier targeting hotels that want branded room key cards — emerged from Eric mentioning offhandedly that a hotel had contacted him. Not from a roadmap. Not from a discovery process. From him texting me at 9pm.

I didn’t do user research. I had a user. That’s different. User research is an approximation of direct contact, designed to work at scale. When you have direct access to the person the product is for, use it. The feedback loop collapses from weeks to hours.

This is also the structural blind spot of SaaS at scale. Stripe, Notion, HubSpot — they can’t do this. They have millions of customers and they manage product decisions through data. That’s the right approach at their scale. But it means every feature is a compromise, and every workflow is a guess about what most customers probably need.

Eric doesn’t need what most customers need. He needs exactly what his operation requires, built around his actual workflow. That’s a different problem.

There’s a phrase going around for this: forward deployed engineering. You don’t hand over a slide deck. You stay in the room until the thing is live. In this case the room was a print shop in Berlin and the feedback loop was a WhatsApp thread.

Software becomes a factory

Something changed in late 2024 that I don’t think has been fully absorbed yet.

Before this, applying AI iteratively to a software project would accumulate errors. Hallucinations, inconsistencies, things that almost worked. The more you asked the model to build on top of what it had already built, the wobblier it got. StrongDM calls the inflection point “compounding correctness” — when long-horizon agentic workflows started improving software rather than degrading it.

That’s what I experienced on this project. The codebase got cleaner as we added to it, not messier. Because the specs were holding structure that the agent could reference, and because the feedback loop with Eric was catching the gaps quickly.

The factory framing: specifications go in, working software comes out. The developer’s job shifts from writing code to writing good input.

flowchart TD
    A["Customer conversation\n(direct contact)"] --> B["Specification\n(structured, precise)"]
    B --> C["Claude Code builds"]
    C --> D["Automated deploy\n(Vercel)"]
    D --> E["Real world test\n(Eric taps the card)"]
    E -->|works| F["Feature shipped"]
    E -->|broken| A
    F --> A

StrongDM talks about “deliberate naivete”: actively unlearning the constraints of the previous era. A full NFC platform — auth, admin panel, customer portal, edge redirect, tap analytics — in three weeks. That timeline felt unremarkable while we were doing it. Looking back, it would have been considered extremely fast two years ago.

The honest caveat: the factory metaphor breaks without good specs and a real customer. Without those two things, you’re not building a factory — you’re just generating confident nonsense at higher velocity. That failure mode is real, and I’ve hit it on projects where I skipped the spec or built in a vacuum.

The video

This is Eric printing. Not an AI. A human, with tools, making something physical. The NFC chip gets programmed after. Both halves matter.

What this means

For a long time, the answer to “I need software but can’t build it” was “buy a subscription and adapt your workflow to what the product offers.” SaaS solved a real problem — software is expensive to build and maintain, so sharing infrastructure across thousands of customers makes sense.

That model still makes sense at scale. But the assumption that software is always more expensive to build than to buy is weakening. A custom tool that fits Eric’s exact operation, built from scratch in three weeks, maintained through a simple spec-and-deploy loop: that’s now a viable option for small operators who couldn’t have considered it before.

The model is not the bottleneck. Spec quality and customer proximity are.

If you run a print operation and want to offer NFC cards without building any of this yourself, the platform is available to other operators at biztrix.vanderlore.de.

Eric has a glass print of the Biztrix logo in his workshop now. I have a bamboo NFC card. Somewhere between those two objects, there’s a WhatsApp thread with several hundred messages that is, in some sense, also the product.

That’s the process. That’s also what’s changing.