u/Warm-Reaction-456

Last month I said no to the biggest deal one of my products has ever been offered... a single contract worth about 2 months of my current revenue (for a whole week afterwards it felt like I had committed a small crime against my own bank account) ask list ran to custom features, priority support and a monthly call and the money was real. My reply took 40 mins to write and came out 4 lines long (I counted becoz apparently thats what guilt does).

I get why we chase these man, revenue is the number everyone else can see while margin is the one only you live with. The trap is that good revenue and bad revenue look identical on the day they arrive (difference only invoices you later).

I've spent 8 years building products and the only reason I recognized this deal is that I took its uglier twin a few years back and paid full price for that lesson.

When a customer pays you, the money moves toward you and in that exact same moment capital moves AWAY from you, your hours and your roadmap slots, the only two things a small product runs on. So every customer is a capital allocation decision whether you file it that way or not. Custom work is capital that gets consumed by one buyer once. The same hours put into the core product get invested for every customer you have and every one you haven't met yet.

The uglier twin was a contract that came with custom everything and for 5 months my roadmap belonged to a company that was not mine. My quiet customers waited politely two of them stopped waiting and the contract ended anyway after 8 months…. so I kept the distraction and lost the compounding and that is the whole tuition bill. There is still a feature flag in that codebase named after the company and I just couldn't bring myself to delete it lol

Saying no last month wasn't discipline but.... The math from that first contract had finally sunk in. The 15 hours a month this deal wanted are going into the thing my quietest customers have been asking about all year and that work ships to everyone at once. I still open the old email sometimes and look at the number but growth for me now means the return on my next 100 hours more than the size of the next cheque. Some cheques that read that way are just expenses with good manners

A couple of years back one of my products had its best traffic day ever a little over 1.1k visitors in a single evening because somebody with an audience mentioned it in passing and I did what every founder does in that situation which is refresh the analytics tab until my thumb was basically on autopilot. Out of that entire spike exactly 1 person paid and that the 1 person turned out to be worth more than the 1100 put together. I don't mean that in the motivational poster way, I mean it in the literal accounting way.

Yk that graph refresh feeling. It's mostly flattery. A visit is about the cheapest thing a stranger can give you, one flick of a thumb on the way to somewhere else and we still treat it like it means something. I have written before about a waitlist of 9 people where 4 turned out to be friends being polite and traffic is that same politeness at scale except visitors never have to meet you. A visitor can't disappoint you and that's exactly why the number feels so good and teaches you nothing.

I have spent the last 8 years building products and most of them billed monthly and the recent ones are AI native... So,

Inside her first week, that 1 customer did things no visitor had ever done for me. She asked for a proper tax invoice within 2 days which meant learning invoicing like an adult instead of forwarding a payment screenshot. Then she asked where her data was stored so I wrote her an honest answer. That part took longer tbh. The third thing wasn't even a request, she had just started using the product for something I never designed it for and that one made me reread my own landing page the way a stranger would. None of this shows up in analytics and every one of them was a business problem and business problems are about the only evidence i have found that a business exists. A thousand visitors will never make you write a refund policy and you can't exactly schedule a call with a bounce rate.

That third thing is where the ego damage is. I had spent 6 weeks on the flagship feature, the one the homepage was built around and she ignored it so completely that for a while I assumed my event tracking was broken. Her whole workflow ran through an export button. When I finally asked her about it on a call, she said the flagship thing seemed nice but the export was why she paid.

Then came the part I couldn't have planned. About 5 weeks after she signed up, 4 new customers arrived across 3 days, all chartered accountants, 2 of them from the same small firm and none of them from any channel my analytics could name. I eventually asked one of them how he found me and the answer was a WhatsApp group. Some room full of CAs where she had posted 2 lines about the tool fixing a thing they all hated. That's the part of a good customer nobody prices in, they can walk you into rooms you could never buy your way into because no ad platform sells placement inside a group of colleagues who trust each other. People file this under word of mouth.

Visitors are painless. They don't email at odd hours or ask for refunds and they never use the product wrong in a way that implicates your design. Customers do all of that and all of it is information and I was avoiding it because it might disagree with me. I kept avoiding it right up until the disagreement started paying my invoices.

So the title exaggerates less than it looks. There is a definition of a lead I've slowly come around to, that someone only counts once they show interest AND can actually be contacted and a visitor clears neither bar.

The payout email landed on a tuesday (104 dollars and change) from a tool I built over 2 weekends about 3 yrs ago and last pushed code to 14 months back. My first reaction was a small flush of embarrassment, smthing you get when a friend asks how the side thing is going and you have to say a number that sounds like a phone bill. Then I looked at what the rest of that tuesday had been which was 6 hours of support and onboarding calls for my bigger product, the one that is growing, one that is supposedly the dream and I sat there for a min doing the math

See Ik how the 100 dollar product sounds. It doesn't pay rent and it doesn't screenshot well and nobody has ever invited me to speak anywhere because of it but it has 13 paying users, 14 in the months when someone forgets to cancel, none of whom have ever emailed me at midnight. It has needed exactly 1 support reply in the last year (someone wanted a proper invoice, 4 minutes of my life) and it is the ONLY product I have ever built that I can describe as finished. Most founders never experience finished. We experience abandoned or we experience on fire and we tell ourselves those are the only 2 states a product can be in.

I have spent the last 8 years building products and tbh for most of that time I measured my own worth by how fast the biggest number was moving

Then there is the math which none of us ever wants to do out loud. My growing product does around 4 grand a month right now and takes something like 50 hours a week to keep moving, which works out to 200 hours a month, which works out to 20 dollars an hour before servers and before whatever my sleep is currently worth. Do the same sum for the tiny product and the calculator gives up, because you cant divide by zero, and I have made peace with the fact that the entire argument of this post fits inside a single error message. MRR leaves you out of the costs. It counts what the customer pays. What the founder pays never shows up and in an early product the founder is nearly always the biggest cost in the building so the figure everyone celebrates is missing the line that decides whether the thing is any good.

If I vanished for a month the tiny tool would not notice and the payout would land on its tuesday like it always does. The bigger product would start dying by the second week because onboarding is me and there is no version of support or the roadmap that doesn't route through my calendar. To a buyer that means the thing they would actually be paying for is me and I am not for sale at that price.

To be clear, I'm not telling anyone to aim for 100 dollars a month and call it a life. The argument was always about the shape. A product that runs without you has a shape you can do more of, more users and more channels and eventually more copies of the whole thing and none of that extra volume ends up on your body. A product that runs on you breaks the moment you try to add more because more customers is more of you and there is a hard ceiling on you that no dashboard shows.

Earlier this year my own dashboard flagged one of my best customers as a churn risk. For close to 4 months she hadn't logged into a small tool I built, the health score had gone red and I had a "we miss you" email sitting in drafts. Then 2 days before I planned to send it she renewed for a full year without saying a word. When I asked what made her stay her reply was exactly 1 line long. The thing had been running fine the whole time she said so why on earth would she log in.

Every number on my screen had just called a perfectly happy customer a problem. It did that because the entire SaaS scoreboard assumes a human is sitting in a chair in front of the software. Daily actives, activation rates, the aha moment, seats, session length, all of it measures people showing up and a product that works best when NOBODY shows up reads like a slow death on those charts. Look SaaS isn't disappearing, I want to be clear about that before anyone reaches for the pitchforks. What is happening is even stranger... The assumptions that made us call something SaaS in the first place are breaking one at a time while most of the industry keeps reporting to a scoreboard built on the old ones.

I have spent the last 8 years building products so read everything below as a guy publicly questioning the scoreboard he stared at every morning for the better part of a decade, with all the bias that implies. and yes, Ik a lot of this started with one customer.

The name gives the game away. SaaS described how the bits reached you and said almost nothing about what you actually got. Back then that meant over the internet instead of on a disc, with the servers in someone else's building instead of a closet behind the reception desk. Salesforce launched with a logo that literally had the word software crossed out so the category was born defining itself by what it wasn't and here we are more than 2 decades later arguing about whether the software part still counts. The delivery war the acronym was named after ended a long time ago. The word survived mostly because the invoice format never changed. SaaS was always more of a billing habit than a technology and a monthly charge for an ongoing outcome is the only piece of the definition that has survived every version of the technology underneath it.

I no longer think she's( the customer) an edge case. I think she's where this is going. The less a person has to do to get the result they paid for the more that result is worth to them and if you follow that logic all the way down, the limit is a product where you pay and the outcome just happens without you touching anything.

There's a catch though and it hurts because value noone notices doesn't get paid for. The invoice lands, the customer looks around for evidence and there's none because the product did its job so quietly it left no fingerprints. The invisible product has a receipt problem. Its hardest job stops being the work and becomes showing up once a month with proof that the work happened.

The software versus service line gets blurry here too, from both sides at once. You never log in to your accountant. You pay a monthly fee, work happens somewhere you cant see, results arrive and at no point in that relationship has anyone asked which spreadsheet the accountant prefers.

The whole industry is still built for the chair. Streak counters in B2B tools, notification badges on things that have no earthly reason to carry a badge, we miss you emails, engagement dashboards, gamified onboarding for accounting software, all of it designed to drag a human back into a screen so a number goes up before the renewal date. I have done every bit of it. I built the streaks and sent the emails and I once shipped a badge because a metric told me to and I knew it was nonsense while I was shipping it. Almost none of it did anything for the customer.

When someone asks me what the next great SaaS product looks like, my best guess is that its the one users never quite know they are using, and that guess comes with an awkward set of consequences nobody in the category feels ready for. How do you get a testimonial from someone who forgot you exist and what does a demo even look like when the entire pitch is that nothing happens on screen. I have started to think retention for these products should be measured as how long a customer can forget about you and still happily pay you.

So if you ask me what SaaS even means anymore, my answer is that it means exactly what it always meant underneath the acronym, a recurring payment for an outcome that keeps arriving.

The watermark news landed yesterday and my feed split in two. Half of it went off to argue about signal robustness and detection thresholds which is fine coz somebody has to. The other half panicked and the panic is the interesting part. A mark that does nothing but record what touched a piece of text should be weather to anyone whose value is real. The thing under threat here is a business model not a language model and I have been thinking on that difference all day.

We have run this experiment before... Goldsmiths have lived with the hallmark for something like 700 years and in all that time the assay punch has only ever ended the careers of people selling brass as gold. Ingredient labels were supposed to kill the food industry. They killed the corner of it selling sawdust as flour. The loudest opposition to any mark comes from whoever's margin depends on the mark not existing. It rhymed with all that so hard I laughed at my phone.

Full disclosure because I'm about to be insufferable, I have spent 8 years building software so my whole business is openly built on the thing being watermarked. The announcement changes nothing about my week. I still flinched this morning though and I want to be honest about the flinch because it's really the subject here. I traced mine to one page on our site where the wording had gotten conveniently vague about how much of a deliverable is machine made. I rewrote 11 words before writing any of this and tbh the 11 words were the harder part

What the mark threatens is undisclosed substitution which is a different thing from using AI. The ghostwritten personal brand is the cleanest example, the personality is the product and the personality is rented by the hour. So is the agency that prices human days and delivers machine minutes where the whole margin depends on the client never asking. Businesses like that sell a belief about how the work happens. The mark just holds the invoice up against the production line.

People who wrote every word themselves are going to get falsely flagged by lazy institutions and they deserve every defense available that's a different essay though and this one is for the accurately accused. Also plenty of quiet AI use is honest. No one reviews whether the accountant used Excel. The question is whether your price depends on the customer believing something false about how the work gets done. If the value survives the reveal then the mark is paperwork.

If it shook you then... Draft the email that discloses exactly how your product gets made, imagine sending it to your 5 best customers and notice which sentence you reach to soften first. That sentence is your answer.

A client called me in June because their agent usage had doubled and their API bill had gone up 9 times and the CFO wanted to know which one of those numbers was lying. Neither was lying. They had simply run into the strangest property of agent economics: the bill grows with the square of how long your runs get, and nobody warns you about squares.

The cleanest way I can explain it is a meeting rule. Imagine a meeting where before anyone is allowed to speak they must reread every word said so far out loud, and the company pays by the word. That's an agent loop. Every turn resends the entire history, so a token written at turn 1 of a 30 turn run gets billed 30 times and the polite little sentence from the opening gets more expensive every single time somebody else talks. Their runs had stretched from 14 turns to 30 as they added capability, and doubling the length of the meeting roughly quadruples the reading. Multiply that by doubled usage and you land neatly at 9x

Para 3 feels late for an introduction but here we are. I have spent 8 years building software and the awkward detail is that we built this client the agent in question which turned the audit into me investigating my own invoice.

So here's the actual math from their logs. A typical run carried a 14k token base, 11k of it the schemas for 25 tools riding along on every call. The agent used 4 of those tools in a normal run, so about a 5th of the bill went to rereading the menu. Across a 30 turn run the total input came to roughly 1.6 million tokens while the model produced about 12k tokens of output, and even at premium output pricing the thinking came to under 5% of the bill. One outlier run had a 38k token search result land at turn 4 and that single blob got reread 26 more times for just under a million tokens, which made one verbose JSON response the most expensive participant in the meeting. The reasoning your agent does is nearly free. What you're buying at scale is re-reading.

The fixes were less about intelligence and more about tenancy. Tool results now expire from context once the step that needed them is done, and anything bulky gets written to a file with only the path staying behind which turns a million token squatter into a 30 token forwarding address. The tool loadout shrank to what the task needs, so the menu stopped renting space. Long runs compact themselves when the summary costs less than the remaining rereads, arithmetic you can do in advance and yes, caching exists and it helps.

Their average run now bills 6 tokens for every unique token added. It used to bill 18 with the worst runs touching 40.

An invoicing product for freelancers brought us a strange pair of numbers in February. Their community loved them and their NPS among long term users was the best I had seen in that category. Meanwhile new user activation was sliding for 18 months. So we watched 30 first sessions and the mystery was dissolved. A freelancer arrives wanting to send one invoice and the create screen asks 14 questions before the send button, about numbering schemes and tax categories and currency behaviour and approval toggles (Sending a first invoice took a median of 19 mins) In their 2021 build the same job asked 5 questions and took 4.

I have 8 years of experience in building software and product rescues keep landing beside the automation work because the same clients own both problems. This one taught me a rule I now check on every SaaS we touch: a product can get better at everything and worse at its actual job in the same year.

The mechanism is a tax that never appears in the feature meeting. When founders weigh a new capability they keep one ledger, the record of what the product can now do. The second ledger rarely gets kept, the one that records what every user must now decide and the tax is regressive. A power user requested each of those 14 questions and uses maybe 4 of them and skims past the rest in a second because expertise makes filtering cheap. The freelancer on day one pays full price at every toggle. Each option costs a glance and a small moment of doubt about whether it applies to them.

Then we read the changelog and nearly every odd question on that screen had a name attached. The conditional templates came from a single customer whose logo was still on the homepage. Of the 23 features we could trace to specific requests, the requesters behind 9 had already left while their features stayed in everyone's way. The roadmap had turned into a museum of customer exceptions and half the exhibits were donated by patrons who no longer visit.

The community forum and the feature board held about 300 recurring voices out of 11,000 customers and posting there selects for exactly the people who live deepest in the product. Listening to the community felt like listening to the customers when it was closer to polling the top 3% on behalf of everyone else. The median customer sends 6 invoices a month and has never written a public sentence about the tool.

The fix ran in two directions. The create screen went back to 3 decisions with sensible defaults and the other 11 moved into settings a user meets only when their own work demands them. Time to first invoice fell to 5 minutes and activation has risen 31% since the April release and the power users barely noticed because their saved configurations survived untouched.

In May a distribution company hired us to automate their order approval flow. The brief was something one we hear constantly: "make it do exactly what we do now." 6 steps are there and 5 of them explained themselves. The 6th held every order above a certain size for 24 hours before confirmation and when I asked what the hold was for, the room gave me 3 answers within a minute. Probably it was compliance. Daniel set it up before he left and it's always been like that. None of the 3 was a reason.

Quick introduction since an opinion needs a source. I have spent 8 years building software and companies pay us to automate flows exactly like this one which is how I know "make it do what we do now" is the most dangerous sentence in the business. It sounds like the safest possible request and it hides the question of whether anyone still knows where the current process came from.

We spent 2 days pulling on the thread before writing any code. The hold turned out to be a workaround for a credit check that used to run in an overnight batch, on a system the company retired 4 years ago. Real time checks replaced it, the batch died and the waiting survived because Daniel left and took the reason with him.

A stranger discovery sat underneath that one. The 4 people running the flow each ran it a little differently with their own shortcuts and judgement calls, so automating meant picking one version to become official. In practice, whoever gets interviewed on mapping day decides. What you end up encoding is one employee's memory of the process not the process itself.

What worried me most though, was the feedback we were about to switch off. The person doing the hold complained about it roughly weekly and complaints like that are information: a human stuck with an annoying step re-examines it on every single run. She had also developed a feel for orders that looked wrong during that pause and over the years she had caught two fraud attempts almost as a side effect. Our automation would have kept her delay and thrown away her noticing and neither would have appeared on any requirements document.

Perfect execution creates its own problem here. A flawless system running a pointless ritual never has a bad day so nobody ever gets a reason to ask what the ritual is for. While humans ran this flow, somebody complained every week and every complaint was a fresh chance to ask why. Once a machine took over that chance would stop arriving. The step would harden into infrastructure and the dashboard would stay green while the world moved on around it.

So we refused to automate the flow as it stood and ran a slower exercise first: every step had to be explained aloud in one sentence by a current employee and we recorded the answers before freezing anything. Two steps had no living owner of a reason and got dropped... The hold became a real time check that takes 40 secs. The automation shipped with a page listing the assumptions it depends on and a date next year when somebody has to re-verify them.

Ask your team why each step of your oldest one exists and then count the answers that begin with "I think" or "we have always." That count is how much frozen memory you are operating on. Our answers fit in a 9 min recording and I would call that file the most valuable deliverable of the whole project

The longest afternoon of my year was a transcript of two AI agents politely refusing to go first. The planner wanted sources from the researcher, the researcher wanted scope from the planner and a customer facing task sat frozen through 55 mins of perfect manners. Nothing crashed, nothing errored and every component worked exactly as designed which was the unsettling part. The system had a meeting and the meeting never ended.

After 8 years building software agents are much of what our clients pay for and we have built multi agent crews too(tidy diagrams and all). This post costs us sales because crews demo beautifully and the diagram alone has closed deals I was in the room for. Production is where the doubt started.

The parts no one puts on the slide fill our incident channel. A retry fires, one agent redoes a step, and its neighbour has already moved on with the stale result. Two subagents contradict each other, both sounding sure of themselves and the orchestrator merges them into an answer that reads clean and is wrong. Every handoff is a full model call, so a task one agent finishes in 40 secs takes a crew 4 minutes at 6 times the token bill. Debugging is the worst part bcoz there is no stack trace, just a 30 page transcript of agents thanking each other while you hunt for the point where the plan went sideways and when you rerun it, it fails somewhere new.

Behind the engineering sits a mismatch of goals that settles the question more than any bug does. Multi agent systems are optimised for autonomy, businesses for predictability and the two pull against each other. The arithmetic is blunt: If each agent does what it's supposed to 95% of the time then 5 in a row gets you a 77% system, which means the pipeline freelances about one run in four. No operations manager alive signs off on that. The same variability plays great in a demo and gets a ticket number in production.

When I ask clients why the crew exists, the answer is usually the software underneath & not the work. Each agent wraps some system that was never built to talk to the others (one per silo). The committee is duct tape over 15 yrs of integration debt and we all congratulate ourselves that the silos are finally cooperating. It looks like an org chart because it is one. A planner hands work to workers, the workers report to a reviewer and every relay is a summary of a summary, so detail bleeds out at each step. The part that gets me is that we spent 2 decades flattening management layers, then turned around and reinstalled them as software. Our last crew burned more tokens talking to itself than it did on the actual task.

We rebuilt that frozen system as one capable agent with better tools and a plain queue and it finishes in under a minute at a 6th of the cost, with a log a junior can read in one sitting. I will grant the fair exception because parallel and independent work like searching 10 sources at once suits multiple agents when the results never need to agree. If you are architecting something this month, list every handoff and ask what breaks when it arrives late or wrong or twice because that list is the real system.

In April a client asked us to figure out why their MCP server wasn't getting traction. It took us about 90 seconds. There were 61 tool calls in three months and 58 of them from their own engineers testing it and the launch itself had gone fine, that wasn't it. Directory listing, an announcement post, some congratulations in the comments from people who never came back. No one had asked out loud, who the user was supposed to be before the build started. I went through the Slack history to make sure and no one ever did.

Quick disclosure since opinions like this need a source: it has been 8 years of me building software and MCP work is now a decent slice of what clients pay us for. So I'm criticising my own dinner. I also built a server of my own during the early excitement and it made me nothing because it solved nothing anyone was actually stuck on. That took me maybe a year to admit.

The confusion I keep seeing is that a server makes your product reachable by an agent and teams treat reachable as if it meant wanted. Integration is real engineering with clear completion criteria, which is why everyone inclines to it.... you can finish it. Whether anyone was ever trying to make an agent do your task and failing, is a much less comfortable question and no amount of merged pull requests answers it.

Meanwhile the directories have filled up with thousands of servers, a big share of them obviously abandoned. When we ask new clients why they want one, the honest answer under the slideware is usually some version of "our competitors have one." I lived through 2022 when every consumer brand shipped a wallet login and an NFT drop that maybe a dozen people touched and this has the same smell. The money is flowing to the gateways and registries and auth layers rather than to the servers themselves.

None of this is the protocol's fault, for what it's worth. It does its one job fine. The problem is discoverability. A human has to find your server among thousands which is the distribution problem software has always had. Then the agent has to pick your tool at the moment of need and anyone who's watched a model with 40 connected tools lean on the same 3 favourites knows how that goes. Neither of those is something a protocol can fix for you. They were the job before MCP existed and they're still the job now.

The test we run now, before anything gets built is that we find 5 real people already trying to make an agent do the task and failing. People who say it sounds useful don't count, you want the ones who tried and got stuck. Then instrument every call from day one and agree, in advance, on the number that triggers a shutdown. Our April client is rebuilding around one workflow two actual customers kept asking for and early usage is already an order of magnitude past the old server. Build it and they will come was a movie line and even in the movie the guy nearly lost the farm doing it.

8 years in software and a decent share of my revenue since 2023 has come from building the exact thing I'm about to argue against. In January a prospect opened a call with "we have budget approved for a RAG system" I asked what questions the system needed to answer and then someone repeated the sentence about the budget. No one could describe the problem although everyone could describe the architecture. I have sat through some version of that meeting maybe 6 times now.

Tbh we have shipped more than a dozen of these and some earn their keep. A support team answering from a stable, tended set of product docs is a perfectly good use of it. RAG isn't dead and anyone telling you it is has something newer to sell you. I just don't think it should be the automatic move anymore, the thing an enterprise reaches for whenever AI and documents show up in the same sentence.

Most of our disappointing projects turned out not to be retrieval problems at all. One client wanted 40,000 documents embedded. Before touching a vector database we listed the 20 questions employees actually asked and more than half were structured things like refund totals and headcounts that belonged in a database query. About 50 documents covered most of the rest. The other 39,000ish were old drafts and superseded policies that contradicted the live ones so embedding the full corpus would mostly have made the wrong ans arrive faster. What they needed was housekeeping which no one budgets for.

Retrieval assumes somebody owns the library  and in most companies nobody has owned it for years. That's usually why they want magic on top of it in the first place. Our humbling version of this was a bot confidently citing a 2019 travel policy that had been replaced twice because nothing in the pipeline knew the word "replaced" Better chunking was never going to fix that. 3 months of deleting fixed it and the model took the blame the whole time for what was really a filing problem.

The architecture is also shifting under all of this. Chunk and embed was a workaround for the tiny context windows of 2023 and that constraint has mostly dissolved. A stable document set can often just ride along in context now… cached. For the rest we let an agent search roughly the way a junior analyst would running keyword queries and opening whatever looks promising. When the answer lives in a system, it asks the system directly instead of a stale copy. Retrieval is still around but it's just one tool the agent sometimes picks up rather than the whole design.

So before the next RAG line item gets approved.. write down the 20 questions it has to answer and go answer 5 of them by hand. That hour will tell you what kind of problem you actually have.

The January prospect ended up with no vector database and their answer quality is the best thing we have delivered this year. I'm still a little embarrassed by how that sentence sounds. RAG will keep running fine in thousands of companies for another decade and honestly that's kind of the point. Things don't become legacy by failing. They become legacy by working early and then nobody thinks to ask again.

Some context on who's writing this... I have built software for 8 years and now run a small AI consultancy. A growing share of our work lately isn't building new products at all, it's rescuing vibe coded ones that already have paying customers.

So I get why security dominates the conversation. The leaked keys and open endpoints are real but security is a known category of problem. You can buy an audit for it and the thing I keep running into on these rescue jobs doesn't have an audit and it bothers me more.

In June a founder brought us a booking product he had vibe coded over a few weekends. It was genuinely good. It was polished and had around 80 paying customers. Then one of those customers asked what happens to the unused part of a plan when you cancel mid month and I watched him open his own product and click around to find out. He wasn't embarrassed. Why would he be? As far as he was concerned, that's just how you find out what your product does. I have thought about that moment a lot since.

Polish used to arrive last. You earned the nice interface after surviving the edge cases and half built software looked half built. The ugliness was information: it told you and everyone else, roughly how much work was left. Now the finished shell turns up on day one, so the missing parts stop announcing themselves. A beautiful screen can't tell you that payment failures were never handled or that nobody decided what a refund should do when it crosses a billing cycle.

Design takes the same hit. When the spacing is right and the shadows are tasteful, a wrong flow gets the benefit of the doubt. That booking product made people create an account before it would show a single available slot. A junior designer would catch that in review but it looked so professional that users assumed the confusion was their own fault and left without complaining. He never even heard about it.

I have mostly stopped calling this technical debt because debt assumes somebody can read the books. Here, the moment a customer disputes a number, the founder has to change behaviour he never understood and no refactor closes that gap. The gap was never in the code.

For the record, we use these tools every day and some of our internal tooling started exactly this way, so this isn't a purity argument and that founder will probably be fine. 80 paying customers buys a lot of time to learn. What's changed is the assumption underneath: that getting to a product faster also gets you to understanding faster. It used to, more or less, because building slowly forced you to understand things as you went. It doesn't now.

If you've shipped something like this then write down the 5 hardest questions a customer could ask about how your product behaves and answer them without opening the app. The ones you can't answer are the parts of the business you don't own yet. Start from there.

A client of mine recently discovered he doesn't know how his own invoices get reconciled anymore. His accountant asked and he had no answer and he called me worried that something was broken. (Proudest I have ever felt about a project in years). The embarrassing part came first though.

It has been 8 years of me building products(mostly MVPs for founders and lately automation for small businesses) and this client runs a plumbing supply company. His bookkeeper Renee lost most of every Friday to matching supplier invoices against purchase orders, around 70 a week, then chasing down whichever ones didn't line up.

I built what the industry trained me to build, which is a dashboard. I added color coded rows, filters, an approve button, a little counter for cleared items. It demoed great, he showed it to his brother, I invoiced and felt good about myself.

3 months later I stopped by and found Renee spending her Fridays inside my dashboard approving green rows one at a time. Green meant the system was already sure, so she was clicking yes on decisions that were already made, 60 times a week because the screen was there and a screen that exists is a screen somebody checks. I had taken a paper job and given it a login. The same job but with better lighting.

Part of that dashboard was for me, if I'm being honest. A job quietly vanishing doesn't screenshot well and I wanted something to show on sales calls.

The rebuild took a fraction of the effort. I deleted the dashboard fr and let the system match and file everything on its own. When two numbers disagree it emails Renee with both documents attached which happens maybe 4 or 5 times a week. She sorts those out and the other 65 invoices go through without anyone looking at them because no one needs to.

So when the accountant asked how reconciliation works these days, he genuinely couldn't say and he called me thinking the quiet might mean a failure somewhere. Man... the quiet was the thing he paid for. He was reporting the absence of work as a bug.

The dashboard isn't completely gone btw. It survives as a screenshot in a deck he shows people because dashboards look great in decks, which is sort of the whole problem. When automation actually works there's nothing to look at, so people keep paying for glowing control rooms over work that never needed watching.

The question I ask before shipping anything now: if this runs perfectly for a month, what does the client actually see? A screen someone checks every morning means I have hired them an employee and called it software. Nothing until something breaks pattern means someone's getting their Friday back even if it makes for a lousy demo.

I stopped by a clients office in March to see how a build was doing. Dana, the office manager, had two monitors going, AI output on the left, original customer emails on the right and a legal pad in the middle where she was ticking off every line by hand. She looked up at me with the tired politeness of someone checking a strangers homework then I realised that the stranger was me.

I have been building products for 8 years(MVPs for founders, full production builds, a lot of rebuilds of other peoples abandoned systems and automations for small businesses as well) and this client was a supplier doing about 80 quotes a week and I had built them the thing every owner asks me for, a system that reads incoming purchase orders and drafts the quotes automatically. It hit 95 % in testing and the demo got actual applause in the conference room.

Irl 95 % meant 4 wrong quotes a week and no one could know WHICH 4. So Dana checked all 80, every morning because one bad quote to a big account costs more than the software ever saved.

I’ll be honest with you… my first instinct was to defend the 95. Then I sat with her timesheet and felt my stomach drop a little. She used to spend about 8 hours a week writing quotes. She was now spending 6 and a half checking them.... and the errors that got through were stranger than her old mistakes ever were. Wrong units on items she would never fumble and a discount for the one customer who never gets one. I had automated roughly 90 minutes and made the mistakes weirder and I got paid for it.

The fix wasn’t more accuracy. I taught the system to know when it was unsure. A repeat customer ordering their usual items sails straight through. Anything new or a little off pattern lands in a review queue instead of going out. About a dozen quotes hit that queue each week. Dana checks those 12 like a hawk and ignores the rest completely and the ignoring is the whole product.

There is an audit that I run on every build now. I add up the human mins spent reviewing what the machine produced. If that number is anywhere near the original task time then the work never left the building. It just changed desks.

Dana still keeps the legal pad in her drawer btw. Doesn’t fully trust me yet which tbh seems fair.

I went back to check on a build 3 weeks after handing it over and the register was still sitting on the desk, thicker than it was before I started.

for context(NOT A PROMO)…I have been building products for 8 years and most of the recent work has been automation for small businesses (the kind of place where the owner still knows every employee by name). This one was a distributor with 6 people taking orders on calls all day, writing them into that register by hand and someone typing the whole thing into their accounting software at night. I built the obvious fix in about 3 weeks and I was proud of it.

Tbh I was annoyed and I went home saying the usual ungenerous things about clients who claim they want to grow but won’t change anything. That opinion lasted about 2 days before it started feeling a little too convenient.

So I went and sat next to the guy for a full day and watched him work which I had never bothered to do before. It took 40 minutes to see it. A customer calls, he’s ordering 9 items, he’s changing his mind on the third one and he is irritated because his own customers are waiting in his own shop. In the old world my guy scribbles it down in 4 secs and keeps the conversation moving. In my beautiful new system he taps through search fields for every single item while a man breathes down the phone at him. My software was correct and it was also slower at the exact moment where speed was the only thing that mattered.

That wasn’t even the real problem though. The register was HIS and he knew which shopkeeper underpays and which one calls at 8am. He knew who says 10 boxes and means 8. All of it lived in his head and the moment it goes into a system anyone can read it and the man who was the memory of the company becomes the man who types things into a phone. No one says that out loud in a meeting, they just tell you they will start using it properly from next month and tbh I would do the same, i have padded code myself to make a job look harder than it was, so I am not pretending I was ever above any of it.

So now I automate the thing the person hates most rather than the thing thats most broken. The first build has ONE job which is to make that person believe I’m on their side. The old way keeps running in parallel for weeks and no one gets scolded for using paper and I look for someone inside the company whose standing goes up when this works because otherwise the whole thing has a shelf life.

That distributor is fine now… took 4 months instead of 3 weeks and the guy I was annoyed at is the one who trains new staff on it. The first question I ask people now has nothing to do with software, I ask who has to change their day for this to work and whether I can sit next to them before we agree on anything.

A client asked me for a dashboard last year and I built him a proper one with 14 filters, date ranges, export buttons and a settings page where he could choose which metrics showed up first. He runs a building supply business of decent size and he had told me that he wanted full visibility into everything… so full visibility is what I delivered and I was fairly pleased with myself on handover day.

Quick background before the rest of this makes sense... I have been building products for 8 years with a long run of MVPs for founders who needed something live yesterday, some full production builds and more rebuilds of other peoples half finished systems than I would like to admit. These days its mostly automation for small businesses, distributors and clinics, the occasional contractor and dashboards are the thing every owner asks for by name because its the only software word they all know.

6 weeks later I checked the logs and he had opened it 4 times. 2 of those were the day I trained him on it and the export button had never been clicked once which still hurts a little. My first reaction was the usual resentment, that I build these things and these guys don’t use them but I have been burned by that exact thought before so this time I just called and asked what was going on, I wasn't accusing him of anything rather I genuinely wanted to know.

He said and I’m paraphrasing it only slightly, that every time he opened it he had to decide what to look at and by 9pm he has no deciding left in him. That answer has been sitting in my head ever since because I counted every feature I gave that man and never ONCE counted the decisions… which filter to open, what date range even matters today, whether a number is bad or just normal or whether to act tonight or let the week close first. I handed him 14 filters and called it power and he experienced it as homework showing up every night from a guy he was paying.

So I threw the whole thing out and replaced it with one text at 8am that never runs past 3 lines. "2 accounts past their credit limit. Millers payment now 15 days overdue. Cement below 30 bags" He doesn’t log into anything or set anything up and on a good day it just says all clear. He reads it in 20 secs with his coffee. It has been 2 referrals since for a build that's maybe a tenth of the engineering the dashboard was and I’m still deciding how I feel about that part.

and I get it man coz I have done this for years and I like building settings pages(thats probably half the problem) A settings page is your own indecision shipped to the customer with a nice UI on top. It feels like generosity while you are building it, look at all this control I’m giving you but really it meant I hadn’t studied his day hard enough to choose for him.

The products people never leave are deciding for them all day. The map doesn’t give me 14 route filters, it draws the blue line and I drive and no one misses the control they gave up. So before any build now I ask what I need to learn about this persons Tuesday so he never has to think about it again and if you are building something right now, go count the decisions your thing hands people before 9am. I never had until that phone call.