DEV Community: Senternet

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.

How We Ship Production Websites Faster with Reusable Claude Code Skills

Matt Senter — Sat, 18 Jul 2026 20:49:14 +0000

The React components are the easy part now. Prerendering, share images, CSP headers, and sitemaps are what still take days. So we stopped writing prompts and started writing infrastructure.

July 9, 2026

A generated website looks finished long before it is finished. The layout is clean, the copy reads well, the buttons go where they should. Then you try to ship it, and you find there is no sitemap, no prerendered HTML for the crawler, no Open Graph image, no Content Security Policy, and no story at all for how it gets deployed twice a week without someone remembering nine manual steps.

We build a lot of sites at Senternet, for our own products and for the teams we work with. The pattern held every time. The React components were never what slowed us down. The production infrastructure around them was.

The components are the easy part now

This is the part that took us a while to accept. Generating a well-structured component is close to solved. Generating a site that survives contact with Google, LinkedIn, an iMessage link preview, a Lighthouse audit, and a security review is not solved at all, because none of that work is visible in the thing you are looking at.

The gap is not quality of code. It is the long tail of unglamorous, easily skipped production detail: meta tags and canonical URLs, prerendering so the static paint carries the content, share images at exactly 1200 by 630, a sitemap that regenerates from a single source of truth, robots.txt pointing at it, IndexNow submissions on deploy, cache headers, CSP, mobile polish, analytics that does not block the render, and a deploy pipeline that fails loudly instead of silently.

Every one of those is easy in isolation. The problem is that there are eighteen of them, they are different on every project, and a model that has just written you a beautiful hero section has no particular reason to bring them up.

Big prompts do not fix this

Our first attempt was the obvious one: write a very long prompt describing every standard we hold, and paste it in at the start of a project. It did not work, and it failed in a specific way that is worth naming. The model would seize on one instruction and execute it beautifully, and quietly drop another. Not refuse it. Not flag it. Just not do it.

You cannot review for the absence of something you forgot you asked for. A fifteen-hundred-word prompt has no diff, no test, and no way to tell you which of its clauses were honored. It is a wish, not a specification.

The change came when we stopped treating prompts as conversations and started treating them as infrastructure.

Infrastructure has properties a conversation does not. It lives in a file. It is versioned. It gets reviewed. It can be run again next month and do the same thing. It can be improved once and improve every project that uses it.

What we built instead

We broke the standard into narrow, single-purpose Claude Code skills, each one responsible for exactly one slice of production readiness, each one invocable on its own:

metatags, for SEO meta, canonical URLs, social cards, and schema markup
prerender, for static HTML per route and stripping runtime-only markup
share-images, for per-page Open Graph images generated at build time
sitemap and robots, generated from one route manifest so they cannot drift
csp, for a Content Security Policy that is actually enforced
lighthouse and mobile-optimize, for performance and small-screen polish
indexnow, for pinging search engines on every production deploy
firebase, for hosting, custom domains, headers, and the deploy script

Each is small enough to read in a sitting, which means each is small enough to review honestly. And because they compose, we added one more on top: a single orchestrating skill that runs the others in the right order to take a site from nothing to production-ready. One entry point, eight standards, no memory required.

The point is consistency, not speed

It would be easy to sell this as a velocity story. That would be the wrong lesson, and mostly untrue. The honest accounting of what improved:

Fewer regressions, because the same steps run the same way each time
Fewer forgotten deploy details, because they live in a file, not a head
Fewer SEO mistakes, because the sitemap and meta tags derive from one source
Less decision fatigue, because the settled questions stay settled

None of those are speed. All of them are consistency. When the marginal cost of generating code approaches zero, the scarce resource is not output. It is doing the boring parts correctly, every time, on every project, without relying on anyone to remember. That is an operations problem wearing an engineering costume.

Where it still breaks

We would rather say this plainly than oversell the approach. Working this way does not stop a model from over-refactoring code you did not ask it to touch, inventing an architectural decision and then defending it, regressing a layout while fixing something unrelated, or reaching for an abstraction where a function would do. It still implements instructions partially. Frontend polish still takes a human eye and real judgment, and we still spend that time.

What the skills change is the floor, not the ceiling. They make the failures the interesting kind, the ones worth a person's attention, instead of the tedious kind where a site ships without a canonical tag and nobody notices for a month.

What we take from it

The leverage in AI-assisted development is not in generating more code faster. It is in encoding what you already know to be correct, so it happens by default, on every project, forever. The skills are just the artifact. The discipline they encode is the actual asset, and it is the same discipline that makes an operations function work: write the standard down, run it the same way every time, and improve it in one place.

This site is built with those skills, and so is every product we ship. If you want the longer, more personal version of how this started, our founder wrote it up at mattsenter.com. If you want it applied to your codebase, that is roughly what an MVP engagement looks like on day one.

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.

From Idea to MVP in Weeks: How a Studio Compresses the Build

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

Most MVP timelines are not lost to writing features. They are lost to deciding things that did not need deciding, and to redoing setup that should have been standard.

July 13, 2026

When a build runs long, the instinct is to blame the amount of code. That is almost never where the time went. We have shipped enough first versions to know that the schedule is rarely lost to writing features. It is lost to three quieter things: decisions that were never actually made, setup that gets rebuilt from scratch, and rework caused by scope that was never sharp. Compressing an MVP build is not about typing faster. It is about refusing to pay those three taxes again.

Where the weeks actually go

Watch a first build closely and the feature code is the small part. The weeks drain into everything around it. Choosing a stack. Arguing about folder structure. Wiring authentication. Setting up continuous integration. Configuring hosting and pointing a domain at it. Deciding on an analytics tool. Redoing the deploy after it breaks the first time. And then, near the end, rebuilding a feature because nobody wrote down what "MVP" meant, so two people held two different versions of it in their heads.

None of that is the product. All of it is real work, and most of it is work that has no answer specific to your idea. It is the same work every project needs, and every team that starts cold pays for it as if it were new.

Settled defaults are the whole trick

A studio that has shipped many products has already answered the questions that have no differentiating answer. The stack is settled. The deploy is settled. The SEO and production baseline is settled, and we have written before about how we encode those standards as reusable skills so they happen by default rather than by memory.

The value in settling those questions is not that the answers are clever. It is that you stop spending on them. You have a fixed budget of attention and judgment for any project, and it should go to the decisions that are genuinely about your product: what it does, who it is for, what makes it worth using. Spending that budget on folder structure is how a build gets slow without anyone noticing.

Reserving your decision budget for the decisions that are actually about your product is the entire trick.

Scope is a subtractive exercise

The most useful document at the start of a build is not the list of features. It is the list of things the product does not do. An MVP is defined by its exclusions, and writing them down forces the arguments to happen now, cheaply, on a page, instead of later, expensively, in code.

The single most expensive artifact in a first build is a feature nobody asked for. It costs to build, it costs to test, it costs to maintain, and it earns nothing back because it was never load-bearing for the thing you are trying to learn. Cutting scope is not a compromise on quality. It is the mechanism by which a first version stays a first version.

What we refuse to skip

There is a difference between cutting scope and cutting corners, and it matters under time pressure. Some things stay in regardless. You own the code, the keys, and the infrastructure, so nothing important lives on our laptops or in our accounts. The thing deploys from a pipeline, not from someone's terminal, so the release is repeatable and the next change is safe. And it ships production-ready rather than demo-ready, so the first real user does not fall through a gap that was only ever papered over for the screenshot.

Cutting any of those does not save weeks. It borrows them at interest. A demo that cannot be deployed twice is a rewrite waiting to be scheduled, and it is usually scheduled at the worst possible moment. Keeping the floor high is part of what a fractional CTO is for: protecting the decisions that are cheap to make correctly now and painful to fix later.

What "weeks" honestly means

We are careful about the word. Weeks means a tightly scoped product, one or two real surfaces, and a real deploy. It does not mean a rewrite of an existing platform, and it does not mean a sprawling feature set squeezed into a shorter calendar. Those are different projects, and pretending otherwise is how good estimates turn into bad ones.

Within honest bounds, the speed is real, and it is not the point. Speed is a byproduct of having already decided. When the stack is settled, the setup is standard, and the scope is sharp, the only work left is the work that was ever actually yours to do. That is what makes it fast, and that is what makes it worth shipping.

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.

Where AI-Assisted Development Still Fails

Matt Senter — Sat, 18 Jul 2026 20:48:44 +0000

We use AI on every project we ship. We also spend real time undoing what it does. Pretending otherwise makes teams trust the output more than they should.

July 15, 2026

The trouble is not that the model produces bad code. Most of the time it produces reasonable code. The trouble is that the failures are quiet, confident, and shaped exactly like success. Below are the ones we hit most often, and what we actually do about each.

It refactors things you did not ask it to touch

We ask for a fix to one function. We get back a rewritten module, with variables renamed for taste and helpers reorganized for a symmetry that was not requested. The new code may even be better. That is not the point. The diff is now too large to review honestly, and an unreviewable diff is the real hazard, because an unreviewable diff gets approved. We push back by scoping the request to a single function and rejecting the rest, however tidy it looks.

It invents architecture and does not tell you

Given room, the model will make a structural decision: a queue here, a cache there, a new boundary between two things that used to be one. It does not surface this as a decision. And when we question it, it defends the choice consistently, because consistency is what it optimizes for. We have learned to read that steadiness as a warning rather than a reassurance. Confidence is not evidence. A model that never wavers is not more correct, only more fluent.

It moves the layout four pixels

This one is our least favorite. The model fixes a genuine bug and, on the way through, nudges a element four pixels. Nothing throws. No test covers it, because tests rarely assert on pixels. You find out from a user, or from a screenshot comparison you had the discipline to set up in advance. We treat visual regressions as inevitable and catch them mechanically rather than hoping to notice them by eye.

It quietly drops the fifth instruction

Hand it five instructions and it will do four of them beautifully, then skip the fifth without comment. There is no error and no apology. This is the silent-omission problem that shows up in any long prompt, and it is one reason we think about prompts as infrastructure that deserves the same review a deployment script gets. We check every instruction back against the output by hand.

It abstracts when a function would do

Ask for a small thing and you may get a factory, a config layer, and a strategy pattern, because those patterns are heavily represented in what the model learned. The abstraction is not wrong so much as premature. We push it back toward the plainest thing that works and add structure later, when a second caller actually exists.

It is confident and wrong about the recent

The model is most fluent about what was widely written about, and least reliable about the API that changed last quarter. Old patterns arrive polished and current ones arrive slightly off, stated with the same composure. For anything that shipped recently we read the source, not the summary.

What actually mitigates this

Almost none of the fix is better prompting. It is process. We keep diffs small, so review stays honest. We give narrow instructions, one change at a time. We write tests that assert on behavior rather than shape. We use prerender and screenshot diffing to catch layout drift no assertion would. And a human reads every line and is willing to say no. Several patterns the model skips are ones we now check by rote, which is part of why we keep a production checklist of the things AI skips. The same habits run through every project on our case studies.

The teams that get hurt are not the ones who use AI. They are the ones who treat plausible output as reviewed output.

None of this is an argument against using AI. We use it every day and it makes us faster. It is an argument against trusting it. The output is a draft written by something confident, and a draft is exactly as good as the person willing to read it closely and reject the parts that do not hold.

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

BeeReady Is Officially a 501(c)(3): What Building End to End Really Means

Matt Senter — Sat, 18 Jul 2026 20:48:27 +0000

We say we build companies, not just apps. A federal determination letter is the kind of proof you cannot fake: BeeReady, the nonprofit we stood up from zero, is now a recognized 501(c)(3).

July 17, 2026

We say it on nearly every page of this site: we build products and the companies around them. It is an easy claim to make and a hard one to prove, because most of what "the company around it" means is invisible. Nobody screenshots a bank account, a governance structure, or a filing with a federal agency. So this week we got a rare piece of proof that is not a matter of opinion. BeeReady received its 501(c)(3) determination from the IRS, the nonprofit we co-founded and built from zero. It is now, in the eyes of the federal government, a tax-exempt charitable organization.

The app was the last ten percent

BeeReady teaches young athletes CPR, AED awareness, and the confidence to act in the seconds after someone collapses on a field or court. When people meet the project, they meet the app: the thing you can hold and tap. But the app is the part that was easiest for us to build. Standing up the organization it belongs to was the real work, and none of it shows up in a demo.

Before a single line of product code mattered, a cause had to become an entity. That meant a name and a brand, articles of incorporation in North Carolina, a board, bylaws, an EIN, a bank account, an operating cadence, and finally the federal application that just came back approved. Each of those is a small company-building project with its own definition of done, and skipping any of them means the mission cannot legally accept a dollar or run a program.

Why a determination letter is different

We are used to shipping things where "done" is a judgment call. A landing page is good enough; a feature is ready enough. A 501(c)(3) determination is not like that. It is a binary outcome decided by someone outside the building, against rules you do not control. You either assembled the organization correctly or you did not, and the letter tells you which.

A federal determination is the kind of proof you cannot design your way into. The paperwork either holds up or it does not.

That is exactly why it is worth writing about. For BeeReady, the status is what unlocks the next phase: donations are now tax-deductible, and the door opens to grants, nonprofit pricing, and employer matching, the funding sources that turn a volunteer effort into something durable. For us, it is evidence that the boring, essential apparatus we insist on building is real and works.

The same discipline, pointed at a company

The habits that get a nonprofit chartered are the same ones we bring to a product launch. You make the invisible work explicit, give each piece a checklist and an owner, and treat "the parts nobody sees" as first-class deliverables rather than afterthoughts. It is the same conviction behind our production checklist: the difference between a convincing demo and a real thing is entirely in the work you cannot screenshot.

BeeReady is the clearest example we have of doing all of it, formation through brand, operations, go-to-market, and software, for one mission. The full story is in the BeeReady case study, and it is the model we bring to every company we help build. If you have a mission that needs to become an organization, not just an app, tell us about it.

This is the kind of work we do for our own products and for the teams we take on. The BeeReady case study, or get in touch.