The future of SaaS is tailored software
A few weeks ago I went to pick up a glass print from a friend’s workshop in Berlin and came home with a product to build. Eric does custom printing on glass, wood, acrylic and business cards. It is a small operation, and he knows his customers by name. While I was there, he mentioned that he wanted to expand into NFC business cards, the kind you tap with your phone to open a URL. I said I could probably build that.
Three weeks later there was a live product, and today it runs at glastrix.com/en/nfc. The recording shows the customer’s side: they pick a material, upload a design, set the link the card should open and add the names for each card. Behind that sit an admin panel for Eric, a customer portal where people change their link, and a redirect that fires when someone taps the card. I didn’t plan to become an NFC product developer, and here we are.
Two things made three weeks possible. Every feature started as a written spec, and Eric answered my questions within hours instead of weeks. Neither of those scales to a SaaS product with millions of customers, and that gap is where tailored software wins.
From order to tap
Most of the system sits around the tap: the ordering, the printing, and the moment a physical card gets bound to a database row. A customer orders online, and Eric gets an email. His admin panel batches the orders into print PDFs, he prints the cards, scans each card’s QR code to link it to its order, programs the NFC chip and ships it. When the card arrives, a tap opens the link the customer chose, and the customer can change that link at any time.
/c/NFC-XXXX) that redirects to whatever link the customer set last.The printing rules
Printing is where things get specific. Eric runs a UV printer, and the files it accepts have rules. White ink goes down first as an underlay, and the machine only detects white elements when they are encoded as roughly 1% black. A design with white text saved as #ffffff gets ignored, and the text disappears from the card. You learn this only by talking to the person who operates the machine.
The batch files follow the machine too. All card fronts for a run go into one PDF and all backs into another, with at most 25 cards per batch, and the admin panel generates both files. The video shows Eric, a human with tools, printing a tray of cards. He programs the NFC chips after the print run, and only then does a card leave the workshop.
What the customer holds
From then on the customer owns the redirect. They log in to the portal and change the URL whenever they like, without emailing Eric or opening a support ticket. The printed card stays the same, and the next tap goes wherever they point it.
- Material
- PVC, bamboo, walnut or metal
- Design
- Their own, UV printed in Eric's workshop
- NFC chip and QR code
- A tap or a scan opens their link
- Portal
- They change the link themselves, at any time
Specs first
The spec before the session
Every feature started as a written spec: what the user sees, what happens in the database, which edge cases exist and what counts as done. I opened Claude Code only once the spec existed. Claude implemented, and I reviewed, tested and deployed. When something broke, we went back to the spec, found what was underspecified, fixed it and tried again.
The spec is also what made the 1% black rule buildable. Without that conversation with Eric, I would have shipped a design uploader that silently swallowed white elements. The cards would have looked fine on screen and come out wrong in print. Writing the spec forced the question, Eric had the answer, and Claude built the rule.
The kanban loop
The workflow around the specs is the one I’ve written about before: a kanban board with clear tasks for each agent session, regular check-ins to reorient, and the discipline to close one loop before opening the next. Each conversation with Eric became a ticket, each ticket a spec, and each spec a Claude session. The kanban kept the work from turning into a pile of half-finished features.
The same discipline held inside a session. Whenever I said “let’s also add X while we’re in here”, things got messy, and the sessions that stuck to the spec worked. Every feature went around the loop below. A deploy to Vercel took about five minutes, and Eric checked each change the way his customers would, with a real NFC tap.
The product harness
Goldens
A spec says what to build, and the harness checks three weeks later that it still works. Each feature got a golden: a concrete, verifiable statement of correct behavior. “The PDF export works” is too vague to check. A golden reads “a bulk order with 5 cards produces a PDF with exactly 5 pages, each showing a different design”, or “white pixels in a bamboo card design are replaced with 1% black before the file reaches the printer”. Each golden ties to a ticket, and each ticket to a conversation with Eric.
That makes the harness as tailored as the product. The goldens hold knowledge that would otherwise live only in Eric’s head: the UV printer’s file requirements, the batch PDF workflow and the edge cases in NFC programming. The platform knows these rules because Eric was in the room, and no generic NFC card platform would.
Smoke tests and risk areas
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. The manual goldens form the second layer, a living checklist of behaviors that need a browser and human eyes. One reads “drag the NFC icon to a free position: the ‘Custom position’ badge appears”. Another reads “scan the QR on page 1 of the bulk PDF: it goes to card 1’s destination, not card 2’s”.
Next to both layers sits a list of 14 documented risk areas, silent failures where nothing visibly breaks. A bulk order returns 200 and never writes to the database. An async regen job fails, and every page of a PDF shows the same design. A printed card’s QR code sends the wrong person to the wrong URL. These failures surface only in real-world use, so the way to catch them is to define what “wrong” looks like before it happens.
The WhatsApp thread that shaped every feature
Voice notes and 9pm texts
Eric was not a client in the usual sense, because he stayed in the loop the whole time. The admin card activation flow changed three times, each time after he sent voice notes about what it felt like to use. One of them asked: “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?” A five-minute exchange like that improved the product without a Figma prototype, a research session or a sprint ceremony.
The hotel variant started the same way. That separate product tier, for hotels that want branded room key cards, began with a 9pm text from Eric saying a hotel had contacted him. It came from no roadmap and no discovery process. User research approximates direct contact so that it works at scale, and I had the direct contact. With the user one message away, the feedback loop shrank from weeks to hours.
The SaaS blind spot
SaaS at scale can’t work this way. Stripe, Notion and HubSpot have millions of customers and steer product decisions through data, which is the right approach at their size. It also makes every feature a compromise and every workflow a guess about what most customers probably need. Eric’s operation has needs most customers don’t share, and he needs software built around his own workflow.
There’s a phrase going around for this: forward deployed engineering. You stay in the room until the thing is live, instead of handing over a slide deck. Here the room was a print shop in Berlin, and the feedback loop ran through Eric’s phone.
Software becomes a factory
Compounding correctness
In late 2024, the sign flipped. Before that, applying AI iteratively to a software project accumulated errors: hallucinations, inconsistencies, things that almost worked. The more you asked the model to build on what it had already built, the wobblier the result got. StrongDM calls the inflection point “compounding correctness”: the moment long-horizon agentic workflows started improving software rather than degrading it.
This project matched that experience. The codebase got cleaner as we added to it, because the specs held structure the agent could reference and the feedback loop with Eric caught gaps quickly. Specifications go in and working software comes out, which is why I call it a factory. The developer’s job shifts from writing code to writing good input.
Deliberate naivete
StrongDM also talks about “deliberate naivete”: actively unlearning the constraints of the previous era. We built a full NFC platform in three weeks, with auth, an admin panel, a customer portal, the edge redirect and tap analytics. That timeline felt unremarkable while we were in it, and two years ago it would have counted as extremely fast.
The factory metaphor breaks without good specs and a real customer. Without those two, an agent generates confident nonsense at higher velocity. I’ve hit that failure on projects where I skipped the spec or built in a vacuum.
The new build-or-buy math
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 there: software is expensive to build and maintain, so sharing infrastructure across thousands of customers makes sense, and at scale it still does. What is weakening is the assumption that building always costs more than buying. A custom tool that fits Eric’s exact operation, built from scratch in three weeks and maintained through a simple spec-and-deploy loop, is now an option for small operators who couldn’t have considered one before.
The model is not the bottleneck; spec quality and customer proximity are. Print operators who want to offer NFC cards without building any of this can use the platform at nfcpress.vanderlore.de. Eric now has a glass print of the NfcPress logo in his workshop, and I have a bamboo NFC card. Between those two objects sits a WhatsApp thread with several hundred messages, and that thread is also the product.