Two Suits.
An A(i) love story, in production — and a real platform I built for the only customer that mattered.
Meet Fefi.
My wife runs a small business.
You know the kind of small business that runs on a notebook only the owner understands? She has been running one of those for years — first in Israel, where she built a real following, mostly by being very good at her job and remembering everyone's kid's name.
Three years ago we moved to the United States. She paused the business — partly to learn where the post office was, partly because every small business reaches a moment where it either grows up or it doesn't, and she was ready for hers.
What she came back with was bigger, broader, better.
This is the story of what it took to build the platform that lets her run it. It's a love story; it's a superhero story; and — because superhero stories are easier to remember when they have receipts — it's also a working production system. Every illustration is followed by a real-world artifact from the system that makes the story not a story.
Enter the Paperwork.
Every story needs an antagonist. This one's antagonist isn't a person.
It is the slow, accumulating monster every small business knows by heart — built out of IRS forms, license renewals, vendor agreements, calendar conflicts, scheduling apps that fixed one problem and created two more, sticky notes about the sticky notes, regulatory deadlines, software subscriptions whose renewal dates nobody can remember, and yards of red bureaucratic tape that wraps tighter the harder you pull.
Most stories about small businesses pretend this monster doesn't exist. They show you the artistry, the customer testimonials, the soft-focus product shots. They edit out the part where the owner is up at 11 p.m. on a Sunday trying to figure out which calendar invite is the source of truth.
I'm going to keep the monster in the story. Because the monster is the story.
The Cost.
Stay married long enough, and you stop hearing what your partner says.
You start hearing what they have stopped saying.
What Fefi had stopped saying, mostly, was about the software running her business. The patched-together calendars she had given up on rebuilding. The three different scheduling apps she had tried, in sequence, and quietly abandoned because each one fixed one of her problems while creating two more. The corners of the work where the tools were costing her the part she was best at — the part where she takes a couple's wedding day, or a six-year-old's birthday, or someone's twentieth anniversary, and makes it feel like a moment instead of a logistics problem.
If you have ever watched someone you love get worse at a thing they used to love because the tools around the thing have gotten worse than the person — you know what I am describing.
She had simply made peace with being slightly less good at it than she could be — because the alternative was spending two hours a night fighting software, and she wanted those two hours for our life instead.
This is the quiet failure mode of "good enough" tools, and it is more common than people admit. The tool gets built for the average. The user is not the average. The user works around it. The user gets used to being slightly worse than they are.
I had been watching this happen for long enough to be quietly furious about it.
The Architect's Eye.
I am not a coder.
What I do is different. When most people look at a complex system — a process, a workflow, a calendar, a queue — they see noise. I see the architecture inside it. The patterns. The people moving through it. The places where the structure is quietly working against the human it is supposed to serve.
For most of my career, that has been my job. See the seams. Ask why. Propose better.
The problem is that proposing better and shipping better are two different sports. I have always had ideas about how things should be built for the people who actually use them. Most of those ideas never got built — not because they were wrong, but because between an idea in my head and a working system there are usually fifteen meetings, three roadmap reviews, and a small army of talented people whose schedules will never quite line up with mine.
The Suit.
I had been working with AI on that gap for a long time. Long before it became a personality trait on LinkedIn.
Here is what I have learned. Good AI, in the hands of someone who already knows what they want to build, is not a brain. It is an exoskeleton. It is the part that takes what you already see, and lets you go and build it at the speed of your own thinking.
The suit does not make the man.
It makes him fly.
The reason most people are disappointed with AI right now is that they are asking it to be the thing the suit goes around. They want it to be the brain, the judgment, the taste, the system thinking. It is not those things. It is the suit. It only flies if you can fly.
What changed for me, after a long quiet practice, was not that I learned to think better. It was that the suit finally fit.
Inside the Workshop.
The illustration above is metaphor. The photograph above is — well, also stylized. But it is closer to what the work actually looks like at 11 p.m. on a Tuesday.
Three monitors. One running the live code. One holding the architecture diagram. One open to the AI chat that is currently typing the next migration. A coffee cup. A printed page of notes. A photo of my wife on the corner of the desk.
This is the suit, in real terms. AI does not sit in some ethereal cloud. It sits in this room, on this desk, doing this typing. Between the screens, every five minutes, a human decision happens. Between the human decisions, every five minutes, a thousand keystrokes happen that I did not have to type myself.
The article from here on out is a tour of what comes out of that workshop.
The AI Architecture.
The suit metaphor is fine for the front of the article. Now the architectural truth of the suit, because this is what AI as exoskeleton actually looks like when it is set up to amplify a single operator instead of replacing one.
The architecture is a hierarchy. I am the Operator. One human, one set of priorities, one accountable signature on every decision.
Directly below me sits the AI Architect — Opus 4.7, the planner. The Architect talks to me, reads the system map, names every parity layer a request will affect, drafts the diff in plain English, and lands a plan with file paths, line numbers, and explicit verification steps before any executor touches the code. The operating principle is simple: the Architect never delegates understanding.
The Architect delegates to three subagent tiers, each with its own role and its own hard rules:
Implementation tier. Sonnet 4.6 floor — never Haiku. Five specialists: Coder, Web, iOS, DBA, Designer. Each one owns a specific surface of the codebase. The Architect picks the right one based on what the change actually touches, hands them a plan, and reviews the work.
Quality & Knowledge tier. Consulted at every change boundary. Researcher (read-only) goes wide on questions before a plan is sound. QA runs the manifest. Security guards the trust boundaries. Memory is the brain-like pipeline — knowledge graph plus drawer system — that holds decisions, rules, and history across sessions so the team never starts from zero.
Operations & Specialists tier. DevOps, Sync (Heavy graduation active), Integrations. Each owns the long-running surfaces of the system — the deployments, the offline-sync wire, and the third-party contracts.
And around the entire perimeter, gating every tool call and every commit at the boundary — the Sentinels. Non-AI hooks. Project-scope and git-scope. Four of them: the Pre-Change Protocol Hook warns when sync-layer files are about to be edited without a knowledge-graph query first. Schema-verify blocks destructive SQL against tables not yet inspected this session. The Parity Check runs as a pre-commit gate and refuses any commit that desyncs the five layers. The KG Refresh auto-rebuilds the system map after every meaningful commit. None of these ask permission. They just enforce.
The Architect plans. The specialists execute. The senses inform. The Sentinels protect. I orchestrate.
This is the difference between AI-as-magic-box and AI-as-exoskeleton. A magic box is opaque, ungrounded, and confidently wrong about half the time. An exoskeleton is composed of named parts, has a defined attack surface, fails in predictable ways, and amplifies the operator instead of replacing them. The suit only flies if you can fly — but only if the suit is also engineered.
The Lab.
She did not hand me a spec.
She did not have to.
For years I had been the only audience for the small frustrations she had stopped naming — the patched-together calendars, the three scheduling apps she had quietly given up on, the corners of the work where the tools were costing her the part she was best at.
That kind of listening is not new for me. It is the same skill that has let me design systems for other people my whole career: hearing what someone actually needs underneath what they say.
So I did not ask her to write a spec. I made her one. The platform I built for her isn't a website. It isn't an app. It isn't a SaaS subscription dressed up as a service. It is a suit.
An exoskeleton specifically engineered around the shape of how she works — that bends around her instead of asking her to bend around it; that runs from her phone, because that's where her life lives; that holds her events the way she holds them, instead of forcing her to hold them differently.
The Five-Layer Architecture.
Now the technical part. Tailored is not a feeling — it is an architecture.
The platform runs across five layers: a public-facing site where her customers find her, an admin where she runs them, a database holding the canonical record, an API tying them together, and a mobile app she actually uses on her phone.
That five-layer count matters. Most small-business software fails because the layers do not agree. The website tells one story, the admin shows another, the mobile app shows a third, the database is the fourth, and the API in the middle has its own opinions. The user lives in the gap between them.
I built a check that runs before every commit, refusing to merge if any of those five layers stop agreeing with each other. Five layers. One decision-maker.
Before any of it became code, it was a sketch on paper. The discipline of designing on paper before opening an editor is what separates an architecture that holds from one that grows by accident.
The Living System.
Here is what those five layers look like now that they are running. Real screenshots, real data — names changed and venues fictional, but every interaction below is a real path through the actual platform.
The admin dashboard is the one screen Fefi opens first every day. It tells her what came in overnight, what's outstanding, what's on the books. The numbers in those tiles are computed server-side from the canonical data — not cached in the screen, not duplicated from somewhere else. If a number changes here, it changed everywhere.
Each lead is one row, one truth — and the same row a customer eventually becomes. There is no "convert lead to customer" ritual she has to remember; the system does it the moment a quote is accepted. The conversion is invisible by design.
The same human you saw in the lead pipeline is the customer here. Same row. Same identity. Edit one, the other reflects it. This is what the parity contract from the previous section enforces: the database does not let the layers disagree about who Elena Vasquez is.
A quote moves from draft → sent → viewed → accepted. Every transition is a server-recomputed truth. She cannot accidentally mark something accepted by clicking the wrong dropdown — the only path to accepted is through the public quote URL she sent the client, and the only thing that triggers it is the client clicking I accept. Money + state = recomputed from canonical sources, never trusted from the client.
The booking page combines everything she needs about a single event: the financials, the venue, the timeline, the audience type (minor / adult — which determines waiver flow), the notes, and a status she cannot accidentally desynchronize from the deposit ledger. This is what people mean by "single source of truth," but in production-system reality, not in vendor pitch reality.
The same data lives on her phone. Same brand. Same gold-on-dark register. Same truth.
Mobile is not a copy of the admin. Mobile is the same row in the same database, rendered for the screen she actually carries. Edit on her phone — admin reflects it within seconds. Edit on admin — phone reflects it the moment connection comes back. The five-layer parity contract guarantees this. The sync engine (next section) makes it work even when the venue WiFi cuts out.
What Her Customers See.
You have seen the engine room. Now the showroom. The five layers I described above are invisible to her customers — and that is the entire point. What customers see is a calm, branded, intentional public surface. Same database, same canonical truth, different lens.
The homepage is the funnel mouth. Every block on it is composable from the admin (page builder, content blocks, testimonials, gallery covers) — meaning Fefi can update the showroom without touching a developer.
The Experiences page is generated from the same services and service_packages tables that the admin uses. Edit a package price in the admin, the public site reflects it on next load. One source of truth.
Each Magic Hour gets its own auto-generated public page with a registration form. The seat counter is real-time. Stripe checkout is wired in. Waivers are emailed automatically on registration. The whole flow — from the moment a parent clicks Register to the moment the signed waiver lands in storage — is one continuous database transaction across all five layers.
The gallery is fed by the canonical media platform — every image is processed server-side with deterministic variants (web-optimized, mobile, thumbnail), tagged for searchability, and access-gated where needed. Self-hosted, not third-party. She owns her own pictures.
None of these pages are static. Every one of them — homepage hero, experiences, magic hour registration, gallery, about — is a render of canonical database content through a strict admin-managed page-builder. The website is the same data, branded and breathing.
The Sync Sequence.
Most production systems break the day the user is offline. Fefi is at venues. Venues have bad WiFi. Sometimes she is in the parking lot. Sometimes she is in a basement ballroom. The platform has to keep working anyway.
Every synced row carries five pieces of metadata: _doc_uuid, _sync_token, _etag, _deleted_at, plus per-field timestamps. The phone holds a SQLite mirror via GRDB; offline writes queue locally and drain on reconnect. The merge is server-authoritative: if the phone and the server disagree about money or state, the server wins. The phone catches up.
She does not know any of this exists. She just knows that when the WiFi at the venue cuts out, her phone keeps working, and when it comes back, nothing was lost.
Magic Hours are her recurring small-format experiences — Glow Paint Nights, themed birthdays, smaller-ticket items. They sit on the same calendar as the bigger booked events. Same source of truth. The calendar is rendering from the same database row a sync from her phone modified an hour ago.
Integrations & Deployment.
The platform doesn't live alone. It talks to the rest of her business — payments, email, vendor calendars, file storage, the public site. Every integration is a small contract with a real external system, and every contract has a fail-safe.
None of these are guessed. Every integration above is in production. Every one of them fails closed — meaning if Stripe is down, the platform queues the charge and shows the user the truth ("we'll process this when payment is back up") instead of pretending the charge succeeded. SSRF guards on URL fetches. RFC1918 / link-local / cloud-metadata blocked. Rate-limit primitives on every public endpoint. The unsexy plumbing that keeps a real platform from getting embarrassed in front of a real customer.
Production runs the same docker-compose topology as local dev. Same containers. Same environment. The only thing that differs is the IONOS box has a public IP and Caddy is auto-issuing TLS for fefimagicalmoments.com. "Works on my machine" stops being a possible failure mode when the production machine and the local machine are running identical containers.
The Symmetric Suit.
Here is the part of the story I did not see coming until I was inside it.
If AI is the suit that lets me fly — that takes my architectural eye and gives it the ability to ship — then the platform I built for her is the same kind of object, in reverse. It is a suit I built for her.
Same logic. Different gift.
She is not an architect. She is an artist. What she does, when the conditions are right, is take a moment in someone's life and design it so well that the customer remembers it for years. That is her gift. The platform picks up the businesswoman half — calendar, invoices, vendor coordination — and lifts it off her, so she gets more of the day to do the thing she does.
The AI gave me back my throughput.
The platform gives her back her artistry.
Two suits. Same architecture of amplification. Two people who get to spend more of their day being the part of themselves they like best.
The Battle.
Every story owes the reader the fight. In a real production system, the fight is mostly invisible — and that is exactly the point.
The double-booking that doesn't happen because the calendar and the API agree on time zones. The waiver that gets emailed automatically the moment a booking is confirmed, signed digitally, archived securely, and pulled up at the venue without anyone fumbling for a folder. The invoice that recomputes itself from canonical data when the package changes. The audit trail that just exists, on every action, because that's how the platform is built — not because someone added it after a panic.
None of those wins are visible. They look like nothing. They look like absence. The two hours she used to spend fighting bad software at 11 p.m. on a Sunday — those don't happen anymore. That's the fight.
The villain in this story does not get a death scene. It just slowly stops mattering.
The Phone at the Venue.
This is what victory looks like. Not a demo. Not a screen recording. Her hand, on her phone, at a real event — checking that today's vendor list is current, the timeline is locked, the family-allergy notes are pulled, and the deposit ledger is reconciled.
The phone shows the bookings on her calendar in the same gold-on-dark register the admin uses. Same brand. Same data. Same truth. One platform, two windows.
If the WiFi cuts out at the venue — and it does — the phone keeps working. The mutations queue. When she walks back into signal, they drain. Nothing was lost. Nothing was ever in danger of being lost.
The Liberation.
What an event business actually is, when the businesswoman half has been picked up by the platform, is the artistry.
It is the moment Fefi walks a wedding planner client into a tasting room and they agree on a palette and the planner notices, two days later, that the chef's tasting menu draft has already arrived and the contract is already signed and the deposit is already invoiced and the venue's preferred vendors are already linked and the client's family-allergies sheet is already attached to every relevant supplier — not because Fefi remembered to do all of that on Tuesday at 9 p.m., but because the platform did it the moment the agreement landed.
It is the moment a six-year-old's birthday becomes about which exact shade of mint green the napkins should be, instead of about whether the deposit was processed correctly.
She didn't get faster. She got back the version of herself she always was when nobody was making her be the businesswoman.
This is what I really built for her. Not features. Not even a platform. I built her back her ceiling.
Red-Team Maturity.
Real production systems serve real customers. Real customers' data deserves real security maturity. The platform went through a red-team pass. Findings closed. Trust boundaries hardened. The audit pages above are real — annotations, ticks, remediated entries, the whole shape of the discipline.
What I will not do here is publish the findings. That is the difference between a writeup and a checklist for an attacker. Show the scar, not the wound — and the scar in this case is a posture: server-authoritative recompute on money and state machines, fail-closed rate limiting on public endpoints, KDF v2 password hashing, TOTP replay protection, HtmlSanitizer on save, CSP enforcement, Caddy auto-TLS in front of the whole thing.
A feature is not finished when it works. It is finished when it fails safely. That is the version of "shipped" that takes a year longer to learn and never comes off your résumé once you do.
The Evening.
Which is, in the end, the actual point of all of this.
I did not build her this platform because she needed it for the business, although she did. I built it because every hour the software costs her is an hour we do not have.
The platform is not, fundamentally, a small-business platform. It is a time platform. It produces hours. The hours have her name on them when she would have spent them on the businesswoman half. They have my name on them when I would have spent them watching her wrestle with bad software and feeling unable to help. They have our name on them when we get to use them together.
The best kind of software, when it is built for someone you love, is not measured in features or uptime or conversion rate.
It is measured in the evenings you get back.
What This Means Next.
I am writing this on a Sunday morning in the part of the year where the work is in. The platform is running. Real customers are using it. The waivers are being signed. The events are being booked. The calendar is doing the calendar's job for the first time in years.
I am not done. There is a list of things I want to add. There always is.
But I have learned enough now to write some of it down, which is what this and the next few pieces will be. I am going to keep doing this — quietly, on weekends, in evenings, in the spaces between the work I do for everyone else. Not because the platform is unfinished, although it always is. Because the experiment turned out to teach me things I did not expect about my own work, about AI, and about what the next decade of building actually looks like for people who already know how to build.
If you are a peer of mine — someone who has been doing this kind of work for a long time, in companies large enough that the path from idea to system runs through the kind of orderly bureaucracy I described above — I think you will recognize something in what I have written here. I would like to hear what you think.
If you are someone considering whether AI is going to obsolete the work you have spent your life learning to do, I think the honest answer, after a year inside this, is: not unless you wanted it to. The thing that used to limit you was almost certainly not your thinking.
It was the suit you did not have yet.
She designs the days other people remember.
I am writing the floor underneath them.