FlowLift is a B2B SaaS product I designed and built end to end, on my own, in seven days. The point of it was never the product. The point was the method: to find out whether a designer directing AI can reach genuine senior depth, or only fast, flat AI output.

So I ran it like an experiment. One self-initiated product, a hard scope, and a rule that nothing shipped unless it would survive a senior design review. What came out is a real activation analytics product with a web app, a marketing site, a tablet layout, and a native iOS app, around sixty screens in total, all built on one load-bearing design system. The whole thing took a week.

It took seven days. The parts people assume AI is bad at, the system architecture, the consistency across sixty screens, the judgment, are the parts I am proudest of. This case study walks through both: the product, and the workflow that produced it, which is the actual subject.

FlowLift is an activation layer for B2B SaaS. It sits on top of the analytics a team already runs, Amplitude, PostHog, Segment, reads the events they already collect with no new tracking code, finds the single most expensive leak in their trial funnel, explains why people drop there, drafts a fix, and then proves the recovered revenue in dollars. Its whole pitch is the opposite of a platform: keep the stack you have, we will just tell you what to fix first.

My role was every part of it, but it is more honest to describe it as two jobs. The first was the senior designer: the strategy, the positioning, the information architecture, the brand, the type and colour system, and the standard that every screen was held to. The second was the director of an AI studio: writing the briefs, running the research and build workflows, reading what came back, and sending most of it back. The AI did the volume work. I made every decision that needed taste, and I made a lot of them, all week.

What this is, plainly: FlowLift has no users. The customer in every screen, InvoicePilot, is invented, and its data is a single hand-reconciled dataset, not a live feed. So there are no usage outcomes to claim. The outcome here is the work itself, and the method that produced it at this speed and this depth.

I did not set out to design a conversion tool. I set out to answer a question I keep getting asked, usually with a raised eyebrow: can you really build serious design with AI, or does it just make the easy stuff faster and fall apart on the hard stuff?

The honest worry behind that question is real. Most AI design output is recognisable on sight: it is flat, it is generic, every screen is its own island, there is no system underneath, and the moment you ask for the unglamorous parts, the empty states, the error states, the consistency of one number across forty screens, it falls over. If that is the ceiling, then AI is a faster way to make a worse portfolio.

So I gave myself a product hard enough to expose that ceiling if it existed. A dense, multi-sided B2B analytics tool is about the least forgiving thing you can design: it lives or dies on data hierarchy, on consistency, on a system that scales across dozens of screens and several platforms. If AI direction was going to break, this is where it would break. I gave it a week, kept myself as the only designer, and made one rule: nothing ships unless it survives a senior review. The rest of this case study is what that produced, and how.

The thing that made this work was not one clever prompt. It was a pipeline, with my judgment as the gate between every stage. I was not asking AI to "design a SaaS app." I was running a process and reviewing the output of each step before it earned the next one.

Three habits mattered more than any single prompt. I built the system before the screens, so that every screen was an assembly of approved parts instead of a fresh invention that could drift. I used AI against itself, pointing reviewer agents at the builder agents' work to find what was broken before I did. And I treated my own attention as the scarce resource, spending it on the decisions that needed taste and automating the ones that needed patience. The sections that follow are the three places that mattered most: the research that changed the product, the system that held it together, and the screens that proved the depth.

My first idea was the obvious one, and it was wrong. Running it through adversarial research on purpose is how I caught that, before drawing a single screen. Used well, AI is not just a generator. It is a critic that does not flatter you.

I started where most people start: an all-in-one "Conversion OS" that would unify analytics, session replay, nudges, experiments, and AI into one platform. It sounds ambitious. So before committing, I ran a research workflow: several agents mapping the market and the competitors, and three more given one job, to try as hard as they could to kill the idea.

All three skeptics held: the all-in-one idea did not survive. The incumbents already cover that ground; "all-in-one of five commodity tools" plays straight into a solo founder's weakest position; and a couple of those pillars, session replay especially, carry legal and infrastructure weight a small team cannot take on responsibly. The idea was a trap. Running it through a review built to catch exactly that is what kept me out of it.

Here is who did what. The workflow pressure-tested the position until the weak version fell apart and the stronger one showed underneath. I read what survived, decided to trust it, and rebuilt the product around it. I would not have gotten there as fast, or as honestly, arguing only with myself.

Here is the discipline that AI output almost never has, and the one I cared about most. Every screen in the product renders the same fictional customer, InvoicePilot, at the same instant in time, pulling from one reconciled dataset. The leak the dashboard flags is the step the funnel dissects, is the cohort the copilot explains, is the fix that gets proven. When the same number has to survive across every screen, you cannot fake a single one.

That number is the Connect step. Of the 2,380 trials that reach it, 1,475 never connect a data source, a 62% drop, larger than every other step combined, worth $28,400 a month. The same figure carries across the dashboard, the leak detail, the copilot, and onboarding. That is not repetition for the case study. That is the product being internally true.

That last rule, AI proposes and shows its reasoning while the human decides, runs through the whole product. Every AI suggestion carries an Apply and a Dismiss, a number-backed rationale, and an audit trail. It is a product opinion, and it is the same argument this case study makes about how the product was built.

If there is one thing that proves this was directed and not generated, it is the system underneath. AI will happily draw you sixty good-looking screens that share nothing. A real product shares everything. So I built the system first and made the screens consume it.

It is structured the way a senior designer structures one: tokens at the bottom, then atoms, then molecules, then organisms. Every component carries its full state coverage, default, hover, focus, pressed, disabled, error, empty, loading, because the states are where products either teach you or abandon you. And it is load-bearing, not decorative: the sidebar, the cards, the tables, and the badges on real screens are instances of these components, so a change to one updates everywhere. The rule I held was simple. A new state goes back into the component. It never gets detached and faked on a single screen.

Four platforms in one week is the part most people will not believe, so here is each one. In the same seven days, the product reached desktop, tablet, mobile web, and a native iOS app design built to Apple's own guidelines, not a shrunk-down website, with a home-screen widget, a lock-screen live activity, and an App Store listing.

If I only showed the wins, this would be a commercial, not a case study. So here is the truthful version: the AI was fast and frequently wrong, and the week was me directing it. Setting the bar, originating the strategy, catching what missed, and deciding what the right answer actually was. That direction is the job, and it is where the design happened.

Left to its defaults, the AI reached for the obvious and the generic every time. The first brand direction came back too loud and too orange; I pushed it through several rounds to the calm green-on-charcoal the product ended up with. The first funnel came back as a plain bar chart, the most generic possible answer, so I rejected it and directed the bespoke activation-path flow that became the product's signature visualisation. Components came back as one-off frames pretending to be a system, so I sent them back until they were real, stateful, and reusable.

None of that is AI failing. It is AI doing what it does, producing a competent average at speed, and waiting to be told it is not good enough. The taste to know it is not good enough, and the specific direction to fix it, is the part that does not automate. I ran adversarial QA passes for the same reason: agents whose only job was to screenshot the work and hunt for what was broken. They caught real defects. I still made the final call on every one.

When the production cost of a screen falls to near zero, the value moves entirely to the decisions: what to build, what to cut, what is good enough, what is not. A weaker designer with these tools just makes bad work faster. The bar did not move. The leverage on it did. That shift, leverage moving onto judgment, is the actual claim I am making here.

It is not magic, and it is not a launched company. FlowLift has no users and the data is invented, so I am claiming a method and a body of work, not a market result. The next honest step for the product is the one no workflow can fake: putting it in front of real growth leads and watching where the story holds and where it breaks.

Because this is how I work now, and I would rather show it than describe it. I can hold a senior bar across a complex product, and I can move at a speed that used to need a team, because I have turned the parts of design that do not need taste into something I direct instead of do by hand. FlowLift is the proof that those two things can be true at once.