DEV Community: Senternet

Pricing Your First Product: Why Free Is the Most Expensive Number

Matt Senter — Tue, 04 Aug 2026 14:15:54 +0000

The hardest part of pricing a first product is not the number. It is that charging money is the only test that tells you whether anyone actually wants the thing. Free postpones that test, and the delay is the expense.

August 4, 2026

Founders will spend six weeks agonizing over a feature and six minutes on the price, and the price is the decision that will teach them the most. The pattern is almost universal: the product is nearly ready, someone asks what it should cost, and the room goes quiet. So the team defaults to one of two escapes. They make it free for now and promise to figure out pricing later, or they glance at a competitor and pick a number a little under theirs. Both of those are ways of not answering the only question pricing actually asks, which is whether anyone wants the thing enough to pay for it. This is a go-to-market decision, and like the rest of the launch it rewards the founders who treat it as work rather than an afterthought, a point we make in our launch checklist.

Free is the most expensive number

Making a first product free feels safe because it removes the awkward part, the moment you ask a stranger for money and find out what your idea is really worth to them. That moment is the whole point. Charging is the only honest test of demand, because a signup costs nothing and a payment costs something, and only one of them tells you the product solves a problem someone will spend to make go away. Free postpones that test indefinitely, and the postponement is the expense. You fill the product with users who like it fine and would evaporate the instant there was a bill, you build a roadmap around their feedback, and you learn nothing about willingness to pay until the day you finally flip the switch and most of them leave. The bill is the experiment. Skipping it does not make the risk go away, it just moves the reckoning to a point where you have built more on top of the wrong answer.

Price on the value delivered, not the cost to build

The most common mistake after charging too little is charging based on the wrong thing entirely. Engineers price on effort, because effort is what they can see: this took a month to build, so it should cost about what a month of work feels like. The buyer does not care what it cost you to make. They care what it is worth to them, and that number has almost nothing to do with your build time. A tool that saves a small business ten hours a month is worth a fraction of that saved time regardless of whether it took you a week or a year to write. Anchor to the value the customer gets, not the labor you spent, and the price you land on will usually be higher and more defensible than the cost-plus number your instinct reaches for first.

Copying a competitor's price copies their business, not yours

Pricing a little under an established competitor feels like the responsible, market-aware move. It is usually a trap. Their price is the output of their cost structure, their funding, their customer acquisition math, and a stage of maturity you have not reached, and none of that is visible from the outside. Undercutting a company that can afford to lose money on every user is not competing, it is volunteering for their worst unit economics without their balance sheet. Use a competitor's price as a data point about what the market has been trained to accept, not as a target to slip beneath. Often the right first move for a new entrant is to charge more and serve a narrower, better-fit customer, which is a healthier place to start than a race you are structurally set up to lose.

You are not looking for the right price, you are looking for the first one

The reason pricing stalls a team is that they treat it as a decision to get right once, and that framing makes it feel enormous. It is not that kind of decision. A first price is a hypothesis you will revise the moment you have real customers, and the fastest way to get the information that revises it is to pick a defensible number and start charging. Most founders invert this and treat pricing like the irreversible calls it is not, the same inversion we described in build versus buy: they agonize over the reversible decision and rush the ones that actually lock them in. The price is cheaply reversible. You will learn more from one month of a real number than from three months of debating the theoretically correct one.

One number and one plan beats a pricing matrix

There is a strong pull toward launching with three tiers, a feature comparison grid, and an annual toggle, because that is what mature products look like and copying the surface of maturity feels like progress. For a first product it is the opposite. A pricing page with three plans forces the customer to do work you have not earned the right to ask of them, deciding which version of a product they do not yet trust is the right fit. It also forces you to invent feature boundaries between tiers before you have any idea which features people actually value. Launch with one plan and one price. You will find out what customers want to pay more for by listening to the ones who ask, and that is far better data than the tier structure you would have guessed at on launch day.

Raising a price is easier than a founder fears

Under every pricing hesitation is the same fear, that a higher number will scare everyone off and the product will sit at zero customers, so a low price feels like insurance. It is the opposite. A price so low that everyone says yes is not a validated price, it is an unanswered question, because you never found the edge where people hesitate, and that edge is exactly the information you launched to get. Raising a price on new customers is a routine, low-drama change that founders build up into a crisis in their heads. The genuinely hard direction is down, walking back a price you set too high after building a business on it. Starting a notch high and adjusting toward the number the market accepts is a far more comfortable path than starting low and trying to claw your way up through customers who signed up precisely because it was cheap.

The price is a product decision you own

The reason we treat pricing as real work rather than a last-minute number is that it is one of the few decisions that touches everything: who your customer is, what you build next, how you talk about the product, and whether the business can exist at all. A product priced at zero attracts a different company than the same product priced to be worth paying for, and the founder rarely notices the substitution until the roadmap has quietly bent to serve people who were never going to pay. Making this decision deliberately, and the same disciplined way on every product, is the same argument we make about the unglamorous parts of building in operational consistency is the real moat. If you are staring at a nearly finished product and cannot bring yourself to name a price, tell us what it does for the person using it and we will help you find the number.

This is the kind of work we do for our own products and for the teams we take on. Go-to-market, or get in touch.

Build vs Buy: What Belongs in Your MVP and What You Should Rent

Matt Senter — Fri, 31 Jul 2026 14:15:35 +0000

There is exactly one part of a first product that has to be yours: the thing you are here to prove. Everything else is plumbing, and plumbing is cheaper to rent than to build. The hard part is drawing the line precisely.

July 30, 2026

Once a founder has settled on a stack, the next decision arrives before a single feature does, and it is the one that quietly decides how long the whole build takes: what to write and what to rent. Every product needs authentication, payments, email, file storage, search, and a dozen other capabilities that are not the reason the product exists. The temptation is to build them, because building is what engineers do and because owning your own auth feels like a badge. It is almost always the wrong call. The stack decision is about the substrate you build on, which we covered in how we choose a tech stack. This is the decision one layer up: how much of the product you should build at all.

Build only the thing that is the reason the product exists

There is exactly one part of a first product that has to be yours: the part that is the actual bet, the thing a founder can describe in a sentence and that nobody can buy off the shelf. Everything else is plumbing. The whole job of scoping an MVP is to spend your build budget on that one differentiator and to rent the rest, because the rest is not where you win or lose. A founder who spends three weeks hand-rolling a login system has spent three weeks not building the reason anyone would want the login in the first place. We ask one question of every capability on the list: is this the thing we are here to prove. If the answer is no, we are looking for something to rent.

The commodity layer is cheaper to rent than the meeting to discuss it

A whole class of problems has been solved so thoroughly, by companies whose entire business is solving them, that rebuilding them is not thrift, it is waste. Authentication, payments, transactional email, error monitoring, and file handling are the obvious ones. These are not hard because someone was lazy. They are hard because they have deep edge cases, security surfaces, and compliance obligations that a small team cannot staff and should not try to. The provider who does this all day has already survived the outages and the audits you have not imagined yet. Renting that is not a shortcut around the work. It is buying a team of specialists for the price of a subscription, and the alternative is being your own worst specialist on your slowest timeline.

Buying is not free, and pretending it is causes the mess

The honest version of this argument admits that buying has a real cost, just a different one. A rented service is a dependency: it has a price that can change, an API that can break, limits you will eventually hit, and data that lives somewhere other than your database. The failure mode is not renting, it is renting carelessly, wiring a vendor so deep into the product that swapping it later means surgery. So we buy behind a seam. The payment provider sits behind our own thin interface, the email service behind a function we own, so that the product talks to our code and our code talks to the vendor. That way a price hike or a shutdown is a bad afternoon, not a rewrite. Renting well is a discipline, not an absence of one.

The trap is the thing that is almost your product

The hard calls are never the obvious ones. Nobody agonizes over whether to build their own email delivery. The trap is the capability that sits right next to the differentiator and feels like part of it. A team building a scheduling product will be tempted to build their own calendar sync, because scheduling is the point and sync feels close to the point. It is not. Calendar sync is a brutal, well-mapped commodity that a specialist API does better than a first-time team ever will, and the actual product is the scheduling logic on top. Draw the line precisely: your differentiator is usually narrower than it feels, and the ring of things around it that feel essential is mostly rentable. Getting that boundary wrong is how a six-week MVP becomes a six-month one.

Reversible decisions get made fast, not perfectly

A build-or-buy call does not have to be right forever, it has to be right for now, and most of these are cheaply reversible if you build the seam. That changes how much deliberation each one deserves. If renting a search service today lets you ship this month, and moving to your own search later is a contained project behind an interface you already own, then renting now is not a compromise, it is the correct sequencing. Build the thing you cannot easily change later, which is usually your differentiator and your data model, and rent the things you can swap when you have the evidence to justify the effort. Most founders invert this: they agonize over the reversible calls and rush the ones that actually lock them in.

One set of rented tools compounds across projects

Because we make this decision the same way every time, we end up renting from a small, deliberate set of providers we know cold. We know their failure modes, their limits, and how to wire them behind a clean seam on the first try, so the commodity layer of a new build is close to solved before it starts. That is the same argument we make about the stack in operational consistency is the real moat: the advantage is not any one clever choice, it is making the unglamorous choices the same proven way on every project so we can spend the saved time on the part that is actually different.

The best code in a first product is the code you did not write

The instinct that building more is building better is exactly backward for an early product. Every capability you rent is a capability you do not have to maintain, secure, and debug at two in the morning, and every line you do not write is a line that cannot break. The measure of a well-scoped MVP is not how much of it the team built, it is how little: a sharp, owned differentiator surrounded by boring, rented infrastructure that just works. That is also the instinct behind knowing which builds should not happen at all, which we get into in when not to build. If you are staring at a feature list and cannot tell which parts are your bet and which are plumbing, tell us what you are trying to prove and we will help you draw the line.

This is the kind of work we do for our own products and for the teams we take on. MVP development, or get in touch.

How We Choose an MVP's Tech Stack (and Why Boring Still Wins)

Matt Senter — Tue, 28 Jul 2026 14:15:30 +0000

The stack feels like an engineering choice, so it gets made on engineering grounds. It is really a decision about how fast you can change the product a year from now. So we pick the boring one on purpose.

July 28, 2026

The tech stack is the first real decision on any build, and it is the one founders most want to get right and most often get wrong. It feels like an engineering choice, so it gets made on engineering grounds: what is fastest, what is newest, what the last hire liked. But the stack is not a taste question. It is the substrate every future change runs through, and the wrong one does not announce itself on day one. It shows up six months later, when a change that should take an afternoon takes a week and nobody can say exactly why. So we treat picking the stack as one of the highest-leverage things we do, and our answer surprises people: we pick the boring one on purpose.

The question is not what is best, it is what is boring and proven

When a founder asks what the best stack is, they are asking the wrong question, because best has no answer without a context. The question we actually answer is narrower: what is the smallest, most proven set of tools that fits this product and the team who will own it. Boring is not an insult in our vocabulary, it is a specification. A boring tool is one that has been in production for years, has answered its hard questions in public, and does not need us to be pioneers for it to work. Every hour we spend being the first to hit an edge case is an hour we are not spending on the thing that is actually the product.

Proven tools have already found the bugs you would have found

The real cost of a new tool is not learning it. It is discovering, one at a time and in production, all the edge cases its authors have not gotten to yet. A framework that a large number of teams have shipped on has had its sharp edges filed down by those teams. The authentication flow that breaks on a certain redirect, the build step that fails only in CI, the library that leaks memory under load: on a proven stack, someone has already hit each of those, written it up, and fixed it. On a fresh one, that someone is you, on your timeline, with your users watching. For an MVP whose whole point is to test an idea quickly, inheriting other people's solved problems is the fastest path there is.

The new variable: what your AI assistant actually knows

There is a factor in this decision in 2026 that did not exist a few years ago, and most founders have not priced it in. We build with AI assistance on every project, and the quality of that assistance is not uniform across the stack. A model is far more fluent in a widely used framework than in a niche one, because it has seen the popular one solved correctly thousands of times and the obscure one only rarely. Choose a mainstream, boring stack and the AI is a strong pair that gets the idioms right. Choose something exotic and the same AI turns confident and wrong, inventing APIs that do not exist and patterns that do not fit. Picking a stack the assistant knows well is now part of picking a stack you can move fast on, and it pushes in the same direction that every other reason already did: toward the proven and the common. The catch is that the AI being fluent does not mean it is right, which is a discipline we cover in where AI-assisted development still fails.

We optimize for the team that will own it, not the one building it

A studio choosing a stack only for its own comfort will reach for whatever it happens to know best, even if the founder will never be able to hire for it. That is a trap. The people who will live with this codebase are the founder's future engineers, not us, and a stack they cannot staff is a slow-motion emergency. So we weight the choice toward what a founder can actually hire and onboard against: a common language, a mainstream framework, tools with a deep pool of people who already know them. It is the same instinct we bring to the end of an engagement in the handoff, applied at the very start. The stack is the first thing you hand off, and you hand it off best by choosing one someone else can pick up.

Where we do reach for something new

Boring by default is a rule, not a religion, and there is one place we break it deliberately. When the novel thing is the product itself, the part that is supposed to be different, that is exactly where a newer or more specialized tool can earn its risk. If the whole point of the MVP is a particular AI capability, we will use the right model and the right framework for that even if they are young, because being conservative there would be building the wrong product safely. The discipline is to spend your novelty budget on the one part that is your actual bet and to be relentlessly boring everywhere else. A build that is exciting in every layer is not brave, it is unfocused, and it will spend its risk on plumbing instead of on the idea.

One stack across projects is a compounding advantage

Because we pick from a small, deliberate set of tools, we get the same benefit across every project that a single team gets across a single one. The deploy pattern is the same, the testing setup is the same, the way share images and sitemaps and headers get produced is the same. We are not relearning the unglamorous parts on each build, which means we get to the interesting parts faster and make fewer mistakes on the way. That is the argument we make in operational consistency is the real moat, and the stack decision is where it starts. A new stack on every project is a new set of surprises on every project.

The stack you can change fastest is the one that wins

There is only one real test of a stack for an early product, and it is not how modern it looks or how it benchmarks. It is how fast you can safely change it the day the market tells you something you did not expect, which for an MVP is most days. A boring, proven, well-staffed, AI-legible stack is not the timid choice. It is the one that keeps the cost of every future change low, which is the only thing that matters when you do not yet know what you will need to build next. If you are about to start a build and are weighing the stack, tell us what you are trying to prove and we will pick the tools that let you prove it and change it fastest.

This is the kind of work we do for our own products and for the teams we take on. MVP development, or get in touch.

The Handoff: Taking a Studio-Built MVP In-House Without Losing Momentum

Matt Senter — Thu, 23 Jul 2026 14:15:25 +0000

The risk is not that a studio builds the wrong thing. It is that the day the studio leaves, the team inheriting the code cannot move at the speed it was built at. A clean handoff is a design decision, not a closing formality.

July 23, 2026

A studio build has a natural ending. The MVP is live, real users are on it, and the founder is ready to run the product with their own team. That moment is usually treated as a closing formality: a repository is transferred, a few credentials change hands, an invoice is settled, and everyone moves on. We think that is the most dangerous way to see it. The handoff is not the end of the build. It is the part that decides whether the build was worth anything, because a codebase you cannot change at speed is not an asset, it is a liability with good production values.

The real risk is a speed cliff, not a bug

When founders worry about inheriting a studio-built codebase, they usually worry about defects: what if something breaks and nobody knows how it works. That is the wrong thing to fear. Bugs are visible, reproducible, and fixable. The failure we actually see is quieter. The studio was shipping changes in hours, and the day the in-house team takes over, the same size of change takes a week. Nothing is broken. The tests pass, the site is up. But the velocity that made the studio worth hiring evaporated on the handoff, because the speed never lived in the code alone. It lived in the context around it, and that context is exactly what a repository transfer does not carry.

We build for the team that will own it, not for ourselves

The single biggest thing that determines whether a handoff goes well happens long before the handoff, in the choices made during the build. A studio optimizing only for its own speed will reach for the cleverest abstraction, the stack it knows best, the shortcut that saves it a day. Each of those is a small debt the receiving team pays with interest, because they have to learn a system that was tuned for someone else. So we make the opposite trade on purpose. We pick the smallest, most boring stack that fits the product and the people who will own it, we resist abstractions that save us a little and cost a newcomer a lot, and we write the code to be read by someone who was not in the room. It is the same discipline we describe infrom idea to MVP in weeks, pointed at a second audience: not just the users, but the engineers who inherit it.

What a clean handoff actually transfers

A repository is the easy part. The hard part is the operating knowledge that never gets committed. How the thing deploys and what to do when a deploy fails. Which pieces are load bearing and which are scaffolding safe to tear out. Why a decision that looks odd was made that way, and what breaks if you undo it. Where the sharp edges are, the third-party quota that will bite at scale, the migration that has to run in a certain order. None of that is in the code, and all of it is what lets a team move fast. A handoff that transfers only the files has transferred the least valuable half. We treat the knowledge transfer as the actual deliverable and the code as the thing it explains.

The first in-house engineer should arrive before we leave

The cleanest handoffs we have run had an overlap. The founder's first engineer, or the lead who will own the product, joined while the studio was still shipping, not after it left. For a couple of weeks they reviewed our pull requests, shipped a few small changes themselves with us on hand, and asked the questions that only come up when you actually try to change something. That overlap is worth more than any document, because it turns the abstract knowledge into muscle memory while there is still someone to ask. A handoff to an empty seat is not a handoff. It is an abandonment with a nicer name, and we would rather stay a week longer than pretend otherwise.

Documentation that survives contact with a new team

Exhaustive documentation is a trap. Nobody reads a hundred-page wiki, and it rots the moment the code moves past it. We write the small amount of documentation that actually gets used: a runbook for the handful of operations someone will do under pressure, a short record of the decisions that would otherwise get silently reversed, and a map of the system that fits on one screen. The test for whether a document is worth writing is simple. If a competent engineer who has never seen the project can use it to do the thing without calling us, it earns its place. If it is there to make the handoff look thorough, it does not. That same instinct, doing the unglamorous work the same way every time rather than performing it, is what we mean byoperational consistency being the real moat.

Owning the code means owning the ability to change it

The only honest test of a handoff is what happens the first time the in-house team ships a meaningful change without us in the room. Not a copy tweak, a real one: a new feature, a schema change, something that touches the load-bearing parts. If that first solo change ships in about the time it would have taken us, the handoff worked. If it takes them five times as long and three questions they were afraid to ask, it did not, no matter how clean the repository looked on transfer day. We aim for the first outcome deliberately, and when a founder needs someone to hold the technical standard through that transition, that is exactly the arc a fractional CTO engagement is built to cover: own the leadership, raise the bar, and hand it off cleanly to a full-time owner.

The handoff is a feature of the build, not a step after it

We say founders own everything we build for them, and we mean it literally: the codebase, the infrastructure, the keys. But ownership on paper is not ownership in practice. A deed to a house you cannot enter is not much of a house. The work of making ownership real is the handoff, and it has to be designed into the build from the first commit, not bolted on at the end. If you are weighing a studio build and worried about what happens when it is over, that worry is the right one to have. Tell us who will own it after us and we will build it for that team from the start.

This is the kind of work we do for our own products and for the teams we take on. Fractional CTO, or get in touch.

When Not to Build: How We Talk Founders Out of Their First MVP

Matt Senter — Tue, 21 Jul 2026 14:15:56 +0000

The fastest way to waste a first build is to build it. Half the founders who come to us for an MVP need a week of validation more than they need a codebase, and we would rather say so.

July 21, 2026

Founders come to us with a build already fully formed in their heads. They have the screens, the flows, sometimes a name and a logo, and what they want from a studio is execution: turn the picture into a working product. It is a reasonable ask, and it is the one we are set up to say yes to. But the most valuable thing we can do in a first conversation is not always to agree. Roughly half the founders who arrive asking for an MVP would be better served by a week of validation than by a codebase, and telling them so is part of the job. The fastest way to waste a first build is to build it before you know it is the right thing to build.

An MVP is a way to learn, not a way to launch

The phrase minimum viable product has drifted over the years into meaning a small first version of the real thing. That is not what it is for. An MVP is an experiment. Its output is not a product, it is an answer to a question the founder cannot yet answer any other way: will the people I think have this problem change their behavior to use what I make. If you already know the answer, you do not need an MVP, you need the actual product. If you do not know the answer, then the MVP has to be designed around the question, and most of the ones we are handed are not. They are designed around the founder's vision of the finished thing, which is a different and much more expensive object.

The test we run before writing any code

Before we scope a build, we try to answer three things with the founder, and none of them requires a repository. First, what is the single riskiest assumption this whole idea rests on. Second, what is the cheapest way to find out if that assumption is true. Third, what specifically would have to happen for us to decide it is false. If the riskiest assumption is that people want the thing at all, code is almost never the cheapest test, and writing it first means spending the most money to learn the thing you could have learned for the least. If the riskiest assumption is technical, that something can actually be built or made fast enough or accurate enough, then a narrow build is exactly right, and we scope it to that one question and nothing else.

The signals that mean stop, not go

A few patterns come up often enough that we treat them as a reason to slow down. When a founder cannot name a single specific person, by name, who has the problem and would pay to have it solved, the idea is still an abstraction and a build will only make the abstraction more elaborate. When the feature list has grown before anyone has talked to a user, the scope is being driven by imagination rather than evidence. And when the honest reason to build now is that building feels like progress and talking to customers feels like exposure, that is the most important signal of all, because it is the one founders are least likely to say out loud. A codebase is a very comfortable place to hide from the question of whether anyone wants what you are making.

What a week of validation actually looks like

Validation has a reputation for being vague, so we keep it concrete. It is usually a week, sometimes two. It means a dozen real conversations with people who have the problem, structured to learn rather than to sell. It often means a landing page that describes the offer as if it existed and a small amount of spend to see whether anyone clicks, signs up, or replies. Sometimes it means a founder manually doing, by hand and badly, the thing the software is eventually supposed to automate, to see if the outcome is even wanted before the machine that produces it gets built. The deliverable is not a product. It is a decision made on evidence instead of hope, and it costs a fraction of a build.

When the answer is genuinely build now

None of this is an argument against building. Plenty of the founders we talk to have already done the hard part. They have the specific customer, they have the demand, and the only real unknown left is whether the thing can be made well and fast. For them, delay is the mistake, and the right move is to compress the build the way we describe in from idea to MVP in weeks and get a real product in front of real users quickly. The point is not to be slow. It is to make sure the speed is pointed at a validated target, so the weeks you spend building are spent on the version of the product the evidence actually supports.

Saying no is what makes the yes worth anything

A studio that will build anything you describe is not doing you a favor. It is selling you certainty it does not have and charging you for the privilege of finding out later. We would rather be the ones who ask the uncomfortable question early, when it is cheap to change course, than the ones who cash the check and hand over a beautifully built answer to a question nobody asked. That discipline is the same operating principle we bring to everything we ship, and it is why how we approach MVP development starts with the decision of whether to build at all. If you are weighing a first build, tell us what you are trying to prove and we will be honest about whether code is the right way to prove it.

This is the kind of work we do for our own products and for the teams we take on. MVP development, or get in touch.

The Production Checklist AI Skips: 18 Things Between a Demo and a Live Site

Matt Senter — Sat, 18 Jul 2026 20:58:12 +0000

Every AI-generated site we have inherited was missing the same eighteen things. None of them are visible in a screenshot. All of them are visible to Google.

July 10, 2026

An AI-generated site looks done. It has a hero, sections, a color palette, and copy that reads well in a screenshot. Then we open the page source, and the production work is missing. Not some of it. The same eighteen things, every time. None of them change what a human sees in a browser. All of them change what a crawler, a link preview, or a cache does with the page. Here is the list we run before we call anything live.

Crawlability and indexing

This is where the gap is widest, because a client-rendered single-page app hands crawlers an empty div and expects them to run JavaScript to fill it. Many will not. We fix that with static work.

Prerendered static HTML per route, so the first paint is real content and not a loading spinner.
A sitemap.xml generated from a single route manifest, so it lists every page and no page twice.
A robots.txt that points at that sitemap and does not accidentally disallow the whole site.
A canonical URL on every page, because a screenshot cannot show you a missing canonical tag.
A meta title and description written per page, not one template repeated across the whole site.
Structured data as JSON-LD for the page types that support it.
IndexNow submission on deploy, so search engines learn about changes without waiting for a crawl.
An llms.txt file describing the site for the AI crawlers that now read it.

Sharing and presentation

A link is content too. When someone pastes the URL into Slack or iMessage, the site is representing itself, and the defaults are usually blank.

Open Graph tags for the title, description, and image.
Twitter card tags, which are close to Open Graph but not identical.
A per-page share image at 1200x630 in PNG. WebP renders unreliably in LinkedIn and iMessage previews, so we ship PNG here even though we prefer WebP elsewhere.
Descriptive alt text on images, which helps both accessibility and indexing.

Performance

Fast is a feature Google measures. Core Web Vitals are a ranking input, and they punish the exact patterns AI scaffolds produce by default.

Largest Contentful Paint coming from the static paint, not from a component that mounts after hydration.
Deferred analytics, so a tracking script never blocks the first render.
Immutable cache headers on hashed assets and short cache with revalidation on HTML, so browsers reuse what has not changed.
Responsive images that serve a size appropriate to the device.

Security and correctness

These are one-line headers that never appear in the design, so they never get added.

A Content Security Policy, plus X-Content-Type-Options and Referrer-Policy.
HTTPS redirects and trailing-slash and cleanURL consistency, so the same page is not served at two different URLs that then compete with each other.

Operations

The last item is the one that keeps the other seventeen from rotting. We want a deploy pipeline that fails loudly, environment config kept out of the bundle, and a build that regenerates the sitemap on every deploy so it cannot drift away from the routes that actually exist. This is the foundation we lay under every MVP we build, and it is why we wrote our post on encoding these standards as reusable skills instead of remembering them by hand.

None of these eighteen items is hard on its own. Any one of them is an afternoon at most. They get skipped for a single reason: they are invisible in the artifact you are reviewing. You approve a demo by looking at it, and looking at it cannot tell you the canonical tag is missing, the share image is broken, or the whole page is an empty div to a crawler. The demo was never the product. This checklist is the difference.

This is the kind of work we do for our own products and for the teams we take on. MVP development, or get in touch.

Why We Treat Prompts Like Infrastructure, Not Conversations

Matt Senter — Sat, 18 Jul 2026 20:57:40 +0000

A prompt you retype is a conversation. A prompt you version, review, and reuse is infrastructure. Only one of those compounds.

July 11, 2026

The most expensive failure mode of a long prompt is not a wrong answer. It is a quiet one. You write fifteen hundred words of careful instruction, the model honors the first twelve beautifully, and it drops the thirteenth without a word. It does not refuse. It does not flag the omission. It just leaves the thing out, and the output looks finished enough that you ship it.

Silent omission is the real risk

A conversation cannot tell you which of your instructions it obeyed. A long prompt has no diff, no test, no report that says clause seven was satisfied and clause nine was ignored. You are reviewing for the absence of something you may have already forgotten you asked for, and absence is the hardest thing in the world to notice. A prompt in that shape is not a specification. It is a wish. Wishes do not compound, and they do not survive contact with next month's version of the model.

What a file has that a chat does not

Infrastructure has properties a conversation never will. It lives in a file. It is versioned in git, so a change to it is a change you can see. It is reviewed in a pull request, where a second person can push back before it runs. It runs again next month and does the same thing. And because it is written down in one place, improving it once improves every project that reads it.

A prompt you retype is a liability you re-incur every time. A prompt you commit is an asset that keeps paying.

Narrow, single-purpose, composable

The practical shape follows from the failure mode. We write prompts as narrow units, each with one responsibility, each small enough to read in a single sitting and therefore small enough to review honestly. When a unit does one thing, you can hold its whole contract in your head and catch the clause that would otherwise go missing.

One job per unit, so its output has a shape you can describe in a sentence.
Composition over a monolith, for the same reason small functions beat a two-thousand-line main().
Reuse across projects, because the unit is a file and not a habit that lives in one person's chat history.

This is the thinking behind the concrete set of skills we built for shipping production websites, each one small on purpose so that it can be trusted and recombined.

You can only test something narrow

Narrowness buys you the one thing a conversation cannot offer: a check. You can assert on the output of a skill that formats a sitemap or writes a set of meta tags. You cannot assert on the output of "make the site good." The instruction has to be specific before the result can be verified, and a small unit forces that specificity where a sprawling prompt lets you avoid it.

The honest limits

None of this makes the model deterministic. The same prompt can still produce different text on different runs, and it will. What the file buys you is a smaller blast radius. When a narrow unit drifts, you see the drift, because you have a fixed contract to measure it against and a history that shows what changed. Nondeterminism does not go away. It stops being invisible.

The artifact is the file, but the asset is the encoded judgment. When a team asks how we build products and the companies around them, this is a piece of the answer: we write down what we already know to be correct, once, in a form that can be reviewed and rerun. That is not a trick for working with models. It is the whole game.

This is the kind of work we do for our own products and for the teams we take on. What we build, or get in touch.

Operational Consistency Is the Real Moat

Matt Senter — Sat, 18 Jul 2026 20:57:07 +0000

When generating code is cheap, the scarce thing is doing the unglamorous parts the same way every time. That is an operations problem, not an engineering one.

July 12, 2026

For most of the last two decades, being fast was the edge. The team that could ship the feature this week instead of next quarter won. That edge is eroding. When a competent model can produce a working landing page in a few minutes, speed stops being scarce. Everyone has it. What almost nobody has is the discipline to ship that page with correct canonical tags, a Content Security Policy that actually loads, and a deploy that fails loudly instead of silently serving a broken build. The generating is cheap. The getting it right, every time, is not.

Consistency is an operations problem, not a talent one

It is tempting to treat reliable execution as a hiring question: find the senior person who remembers the eighteen steps and never skips one. That is not a system. It is a single point of failure with a salary. The moment that person is on vacation, distracted, or gone, the eighteen steps become fifteen, and the three that got dropped are the ones nobody notices until a customer does. A real operations function does not depend on anyone remembering. It makes the correct thing the default thing, so the right outcome happens whether or not the person who set it up is still paying attention.

What encoding consistency looks like

In practice this means moving standards out of heads and into the system itself. A few patterns do most of the work:

A single source of truth that downstream artifacts derive from. Our routes generate both the sitemap and the prerender targets, so the two cannot drift apart. There is no second list to update and forget.
Checklists that execute rather than checklists that are read. A document you are supposed to consult is a suggestion. A script that runs the steps is a guarantee. We treat prompts and procedures the same way, which is the argument we made in prompts as infrastructure.
Tests that fail when a standard is violated. If a rule matters, something should turn red when it is broken. Otherwise the rule is folklore.
Defaults that are correct, so the lazy path is the right path. The easiest thing to do and the correct thing to do should be the same thing. When they diverge, people take the easy one, and they are right to.

Why this compounds

The reason to encode a standard rather than remember it is not tidiness. It is compounding. A standard improved once, in the code or the pipeline, improves every future project that inherits it. A standard that lives in someone's head improves exactly one project, and only for as long as that person stays engaged. The first kind of improvement accrues. The second evaporates. Over enough projects, the gap between a studio that encodes its practices and one that reteaches them each time is not small. It is the whole difference in output quality.

The advantage is not doing something brilliantly once. It is doing it correctly the four hundredth time, when nobody is watching.

It is not just code

The same logic governs everything that repeats. A hiring loop that asks the same questions and scores them the same way produces comparable decisions. An onboarding path that is the same for every new person means nobody starts with a worse first week by accident. Incident response that follows a written sequence stays calm because the sequence, not adrenaline, is driving. A weekly operating cadence that always covers the same ground surfaces problems while they are still cheap. This is what a fractional COO actually builds: a machine for making the correct thing the default thing, across the company and not just the codebase. When we build a product and the company around it, this is where most of the durable value ends up, which is why so much of our case study work is operational rather than purely technical.

Moats used to be built from secrets: a patent, a proprietary dataset, a distribution deal no one else could get. Those still matter, but they are harder to hold when capability is widely available and cheap to reproduce. Increasingly the moat is built from follow-through. The company that does the unglamorous parts the same way every time, long after the novelty has worn off, is the one that is still standing when the easy advantages have been competed away.

This is the kind of work we do for our own products and for the teams we take on. Fractional COO, or get in touch.

How to Hire Your First Engineer When You Are Not Technical

Matt Senter — Sat, 18 Jul 2026 20:56:31 +0000

You cannot evaluate the code, so you have to evaluate everything around it. The first engineer is the one hire where getting the process right matters more than getting the resume right.

July 14, 2026

The first engineer is the hardest hire a non-technical founder ever makes, and not because of the salary. It is hard because you cannot yet judge the work. You can read a resume, sit through an interview, and still have no way to tell competent from confident. Worse, this one person sets the habits the codebase will keep for years: how things get tested, how they get deployed, whether anyone can pick the work up later. Hire well and the next five hires are easier. Hire badly and you inherit a system only one person understands, and that person is now hard to replace. So you do not try to evaluate code you cannot read. You evaluate everything around it.

Hire a generalist who ships, not a specialist

Founders often write the job description for the company they hope to be in three years, and they end up asking for a specialist in a stack that does not exist yet. The first engineer should be the opposite: a generalist who is comfortable owning the whole thing, from the database to the deploy, and who would rather ship a plain version this week than design the perfect one for a month. Depth comes later, with the second and third hires. What you need first is someone who reduces the number of unknowns every week, not someone who is the best in the world at one layer of a product you have not validated.

You are hiring an engineer, not a cofounder replacement

Be careful with the candidate who wants to redesign everything before they have shipped anything. It reads as ambition, and sometimes it is, but for a first hire it is usually a warning. The person who says the current approach is fine for now and here is the one thing I would change first is almost always more valuable than the person with a grand rewrite. You want judgment about what to leave alone, which is the same instinct that makes a goodfirst month of a technical engagement productive. A first engineer who cannot resist rebuilding the foundation will spend your runway proving they are smart.

How to evaluate work you cannot read

You have more signal than you think, it is just not in the code. Can they explain a technical trade-off to you in plain language, without making you feel stupid and without hiding behind jargon? That is the single most predictive thing you can test, because it is what you will rely on every week once they are hired. Ask them to walk you through something they built and why they made the choices they made. Listen for whether they talk about the users and the constraints, or only about the technology. And take references seriously, especially the question of whether the people who worked with them would work with them again. A strong reference from a former teammate outweighs a polished interview every time.

The paid trial is the real interview

Nothing you learn in conversation matters as much as watching someone do a small piece of real work. Carve out a genuine task, something you actually need, and pay them fairly to do it over a few days. Not a whiteboard puzzle and not free labor, a real scoped problem with a real deadline. You will learn in a week what months of interviews would hide: whether they ask good questions before they start, whether they communicate when something is blocked, whether they ship something that works or something that demos. Removing that uncertainty early is the same logic that lets a studio gofrom idea to MVP in weeks, and it applies just as cleanly to a hire.

What good looks like

Ninety days in, a good first engineer has made themselves legible. You know what they are working on and why, in plain language, without having to ask. Work ships on a predictable rhythm rather than in heroic bursts. And there is a written trail, the smallest amount of documentation that lets the next person understand the system, because the first engineer knows they will not be the last. If you are making this hire without a technical partner to lean on, this is exactly the kind of decision afractional CTO is built to de-risk: we run the search, structure the trial, and read the work you cannot. Tell uswhere you are stuck and we will help you make the call.

This is the kind of work we do for our own products and for the teams we take on. Fractional CTO, or get in touch.

What a Fractional CTO Actually Does in the First 30 Days

Matt Senter — Sat, 18 Jul 2026 20:55:59 +0000

The first month of a fractional CTO engagement is mostly listening, measuring, and fixing the two things that are quietly costing the team a day a week.

July 14, 2026

People expect a fractional CTO to arrive with a rewrite in one hand and a roadmap deck in the other. We do neither in the first month. A rewrite is a guess dressed up as progress, and a roadmap written before you understand the team is fiction. The first 30 days are diagnosis, two or three high-leverage fixes, and a set of standards that will outlast the engagement. That is the whole job at the start, and it is enough.

Week 1: listen and measure

We talk to every engineer individually. Not a kickoff meeting, a conversation, one person at a time, where it is safe to say what is actually wrong. Then we read the code, but we read the pull requests and the incident history first, because they tell you how the team really works rather than how it wishes it worked. We time the build. We time the deploy. We count the manual steps between a merged change and a change your customers can see. We ask what everyone complains about, and then we check whether the complaint is the cause or the symptom. A team that complains about slow releases often does not have a release problem. It has a testing problem that nobody has named.

Week 2: fix the tax

There is almost always a recurring cost nobody has priced. A test suite that takes twenty minutes. A deploy that needs a specific person awake at a specific hour. A staging environment that lies about what production will do. These are taxes. Every engineer pays them every week, and because the cost is spread thin, no one has ever put a number on it. We put a number on one of them and fix it. Fixing a single tax returns time every week for the rest of the company's life, and it does it before we have touched a line of architecture. That order matters. Architecture is where new CTOs like to start because it is the most fun to talk about. It is rarely what is costing the team a day a week.

Weeks 3 and 4: write the standards down

By now we know enough to write things down. How code gets reviewed. How it gets deployed. What "done" means, precisely, so that two engineers agree without a meeting. What the on-call expectation is, so that nobody guesses at 2am. The standards that stick are the ones that live in a document that executes: a pipeline, a template, a check that fails loudly. A standard that is read once and then forgotten was never a standard. This is the quiet work that makes an engagement outlast the person who did it, and it is closely related to why we think operational consistency is the real moat for a small company.

What we deliberately do not do

We do not rewrite the codebase. We do not replace the stack because it is not the one we would have chosen. We do not hire before the process is clear, because a new hire dropped into an unclear process just adds a person to the confusion. And we do not introduce a process the team is too small to sustain. Most legacy code is load-bearing and boring, and that is fine. Boring code that ships is worth more than elegant code that is still being planned.

What good looks like at day 30

The founders know what they own technically, in plain language, without us in the room. The team ships without a hero, because the process does the work the hero used to do. And the roadmap has a cost attached to each item, so that the next decision is a trade rather than a wish. A fractional engagement only works if it comes with real authority and a real exit. The goal is to make ourselves unnecessary, and to leave the team faster than we found it. If that sounds like the arrangement you want, this is roughly how we run a fractional CTO engagement, and you can tell us what is slowing your team down.

This is the kind of work we do for our own products and for the teams we take on. Fractional CTO, or get in touch.

The Founder Bottleneck: When to Bring in a Fractional COO

Matt Senter — Sat, 18 Jul 2026 20:52:34 +0000

The company does not slow down because the work is hard. It slows down because every decision still routes through one person, and that person is out of hours.

July 16, 2026

Most early startups that feel slow do not have an operations problem in the way founders describe it. The team is capable, the product is moving, the work itself is not unusually hard. What has happened is quieter and harder to see from the inside: the founder has become the operations. Every approval, every hire, every vendor decision, every unresolved question routes through one person, and that person is now the constraint on how fast the whole company can move. The founder bottleneck is not a failure of effort. It is the natural result of a company that grew faster than the systems around it, and it is one of the clearest signals that it is time to bring in a fractional COO.

The symptom is not chaos, it is a calendar

You would expect a bottlenecked company to look chaotic, but it usually does not. It looks like a founder whose calendar is full of fifteen-minute decisions. Should we use this tool or that one. Is this hire approved. Can someone unblock the contractor. None of these is hard on its own, and that is exactly why they pile up: each one is faster to answer than to delegate, so the founder keeps answering them. The tell is not a fire. It is that the real work, the thinking only the founder can do, keeps getting pushed to nights and weekends because the days are spent being the switchboard.

What actually breaks when the founder is the system

When operations live in one person's head, three things fail predictably. Decisions wait, because the queue is only as fast as the founder can clear it. Quality drifts, because there is no standard way to do recurring work, only the way the founder happened to do it last time. And new people take far too long to become useful, because onboarding is not written down anywhere, it is transmitted by interruption. This is the same failure mode we described in operational consistency is the real moat: when the work is not encoded, it cannot be handed off, and everything that cannot be handed off eventually lands back on the founder.

A fractional COO does not add process, it removes you from the loop

The instinct many founders have is that hiring an operator means adding overhead: more meetings, more process, another layer to manage. Done well, it is the opposite. A good fractional COO's first job is to find the recurring decisions the founder is making by reflex and turn them into something the team can run without asking. That means an operating cadence the company follows on its own, hiring and onboarding that work from a written playbook rather than a founder's memory, and the back-office systems, finance, vendors, and tooling, chosen and wired together so they run quietly. The goal is not to insert a new person between the founder and the work. It is to make most of the work stop needing the founder at all.

When it is too early, and when it is exactly right

This can be premature. If a company is still three people deciding what to build, there is not enough recurring operational load to systematize, and the honest move is to keep the whole team close to the work a while longer. The moment changes when the same operational questions start repeating, when a founder can feel themselves answering the same kinds of things every week, and when good people are idle because they are waiting on a decision only the founder can make. That is the signal. It often arrives at the same stage as the technical version of the problem, which is why some companies bring in operational and technical leadership together, the way we describe the technical side in what a fractional CTO actually does in the first 30 days.

What good looks like ninety days in

Ninety days into a working engagement, the founder's calendar looks different. The fifteen-minute decisions are being made by the people closest to them, against a standard everyone can see. Hiring runs on a loop that does not require the founder to be in every conversation. The back office runs without anyone thinking about it. Most importantly, the founder has their hardest hours back for the work that genuinely only they can do. If your company has quietly organized itself around you and you can feel the drag of that, this is exactly the constraint a fractional COO is built to remove. Tell us where things keep slipping and we will be straight with you about whether the timing is right.

This is the kind of work we do for our own products and for the teams we take on. Fractional COO, or get in touch.

Go-to-Market for Technical Founders: A Launch Checklist

Matt Senter — Sat, 18 Jul 2026 20:52:01 +0000

The launch is not the day you ship. It is the six weeks of positioning, surfaces, and measurement around the day you ship. Most technical founders only do the middle.

July 16, 2026

Technical founders tend to treat the launch as a moment. You merge the branch, you flip the flag, you post the link, and you wait. But a launch is not a moment. It is a system with a before, a during, and an after, and the part that decides the outcome is the part that happens before anyone can see your work. We build products and the companies around them, and the pattern we see most often is founders who ship well and launch poorly. The checklist below is how we close that gap.

Before: weeks minus four to minus one

Positioning comes first, and it comes before code is even done. Write one sentence that says who the product is for and what it replaces. If you cannot name what the user stops doing once they adopt you, you do not have positioning yet, you have a feature. Everything downstream depends on that sentence.

The site says what the product does. The words on the page and the experience inside the product must agree. When they disagree, visitors trust neither.
Pricing exists and is visible. A price is a positioning statement. Hiding it does not remove the question, it just moves the answer out of your control.
You can be found. That means an SEO-complete site: prerendered pages, a sitemap, meta tags, schema, and an llms.txt so AI crawlers can read you the same way people do.
Instrumentation is live before traffic is. You cannot retroactively measure a launch. If the events are not firing on day zero, that data does not exist.

During: launch week

Pick surfaces deliberately. Match the surface to the audience instead of posting the same thing everywhere and hoping. Show up as a person, not a brand account, because people answer people. Reply to every comment, ship a changelog so the release feels alive, and set your own expectations: the traffic spike is the least valuable thing that happens this week.

The spike is vanity. The people who bookmark you and come back in three weeks are the launch.

After: weeks one to six

This is where compounding lives, and it is the phase founders skip. Take the questions people actually asked you during launch and turn each one into content that answers it. Search rankings take weeks to settle, so the post you publish in week three is doing its real work in month six. Watch activation rather than signups. A signup is a promise, an activated user is a result. If you want to see how we think about the durable part of a release rather than the visible part, our go-to-market work is built entirely around this phase.

Measurement: one number, chosen up front

Before you launch, define the single number that would mean it worked. Signups is almost never that number. Something like users who reached the core action within seven days tells you whether the product landed, and it is the only figure worth reacting to in the noise of launch week. Decide it in advance so you are not tempted to rewrite the definition of success to match whatever happened.

What technical founders get wrong

The failure modes are specific and repeatable. You ship a feature list where a claim was needed. You believe the product speaks for itself, which is a comforting thing to believe and rarely true. You treat marketing as beneath engineering, so it gets the least of your attention and returns the least. And you go quiet the week after launch, which is exactly when the audience is warmest and most willing to hear from you. The engineering discipline that makes your product good is the same discipline that would make the launch good, if you pointed it there. We treat the pre-launch surfaces, the same way we treat a production checklist: as things that either exist and pass, or do not. You can see the outcomes of that approach across our projects.

Distribution is a build problem. It has requirements, a definition of done, and a way to be tested, and it rewards the same rigor you already bring to code. Treat it like one.

This is the kind of work we do for our own products and for the teams we take on. Go-to-market, or get in touch.