DEV Community: Matt Senter

What Will Be the First Agent-Native Programming Language?

Matt Senter — Tue, 04 Aug 2026 15:20:34 +0000

Programming languages were designed for humans to instruct machines.

Their syntax reflects that history. We use readable variable names, memorable keywords, indentation, comments, files, classes, and abstractions that fit human mental models. Compiler errors are written for people. Documentation is organized for people. Source repositories are structured so people can navigate them.

But people are quickly becoming less responsible for writing the actual code.

Through Senternet, the software studio where I build products and experiment with AI-assisted development, I now create much of my software by directing coding agents. I describe what I want, review the result, test the behavior, and send the agent back to fix whatever is wrong. The agent still produces TypeScript, Python, SQL, and other conventional source code, but increasingly that feels like an artifact of the existing ecosystem rather than a requirement of the work.

The agent is writing human-readable code primarily because our compilers, libraries, operating systems, APIs, package managers, and deployment infrastructure expect it.

That raises a question I cannot stop thinking about:

What will be the first programming language designed primarily for agents rather than humans?

Human-readable code is becoming an intermediate format

For most of computing history, source code had two audiences.

The first was the computer that would compile or interpret it. The second was every human who might need to understand, debug, maintain, or extend it later.

That second audience shaped nearly every major language-design decision.

Python emphasizes readability. Ruby attempts to feel natural and expressive. TypeScript adds structure that helps large groups of people reason about JavaScript. Rust makes ownership and memory safety explicit so developers can understand and control behavior that other languages might hide.

These are valuable features because human attention has traditionally been the scarce resource.

Agentic coding changes the economics.

An agent does not need syntax that is easy to type. It does not need keywords that are easy to remember. It does not need a language that can be taught in a semester or explained in a shelf of books. It does not become fatigued while navigating a large repository. It can process representations that would be tedious, verbose, or incomprehensible to a person.

It may benefit from very different properties:

unambiguous semantics
compact token representation
explicit dependencies and side effects
deterministic transformations
formal verification
automatic parallelization
machine-readable diagnostics
built-in provenance
incremental compilation
hardware-specific optimization
direct expression of constraints and tests

Once agents become the primary authors of software, human readability stops being the central design constraint.

It does not become worthless. It becomes a generated interface.

The machine-native representation could become the source of truth while humans receive whatever view is most useful at the moment: an explanation, a diagram, a behavioral specification, a security report, a test plan, or even generated TypeScript.

Human-readable code may eventually be no more fundamental than a graphical view of a database schema.

Why agents still write Python and TypeScript

The largest obstacle to any new programming language is not its syntax.

It is the ecosystem.

A new language needs compilers, debuggers, libraries, documentation, package management, editor support, deployment tooling, security analysis, and access to existing platforms. Developers are reluctant to adopt a language that makes them rebuild everything they already have.

Agents do not eliminate this problem, but they may dramatically reduce it.

Historically, a new language also had to convince millions of people to learn it. Developers needed training, examples, books, community support, and enough confidence to risk their careers and companies on unfamiliar technology.

An agent does not need months of training. Once a model or coding system can reliably produce a language, every user of that system gains access to it immediately.

That removes one of the largest historical barriers to language adoption.

The ecosystem problem remains, which means the first successful agent-native language will probably not replace Python, JavaScript, Rust, and C++ all at once. It will absorb them.

It may compile through LLVM, target WebAssembly, call existing C interfaces, import current packages, and communicate with established APIs. It may begin as an intermediate representation hidden beneath a coding agent rather than a language developers knowingly select.

The transition could happen without most people noticing.

Parts of this are already happening

There is not yet a widely adopted, general-purpose programming language written and consumed primarily by agents. There are, however, several early projects moving in that direction.

Researchers introduced Quasar in 2025 as a language for code actions performed by large language model agents. Agents commonly generate Python when they need to call tools or construct control flow, but the researchers argued that Python lacks the performance, security, and reliability features needed for this work.

Quasar adds automated parallelization, uncertainty tracking, and mechanisms for validating potentially unsafe actions. In the current implementation, the model writes a restricted subset of Python that is transpiled into Quasar. The researchers reported a 42 percent reduction in execution time when parallelization was possible and a 52 percent reduction in required approval interactions when its security mechanisms applied.

Quasar is not the final form of an agent-native language. The agent still emits Python-like code. But it demonstrates the pressure clearly: a language designed for people may not be the best execution model for agents.

Pel is another experimental language created specifically for orchestrating AI agents. It uses a minimal grammar and emphasizes constrained generation, capability control, inter-agent communication, safe execution, and automatic parallelization.

Pel is influenced by languages such as Lisp, Elixir, Gleam, and Haskell, but its design assumes that ease of reliable generation by a model is itself a language feature.

That is a meaningful change in priorities. Traditional language designers ask whether syntax is understandable to a person. Agent-native language designers may instead ask whether a model can generate it consistently, validate it mechanically, and recover from errors without human intervention.

Coding agents are also beginning to demonstrate that they do not need to learn unfamiliar languages the way humans do.

In a 2026 study of coding agents working with esoteric programming languages, leading agents frequently wrote Python programs that generated and debugged the unfamiliar target code. When researchers prohibited this metaprogramming strategy, performance declined substantially.

That is a primitive but important form of the future I am describing.

An agent can infer a target representation, build a generator for it, test the result, and revise the generator. It does not need to understand or maintain the target code in the human sense. The target language is simply another machine representation it can manipulate.

The first agent-native language may not look like a language

When people imagine a new programming language, they usually imagine new syntax.

That may be the least important part.

An agent-native language could be a structured representation of:

desired behavior
interfaces
constraints
permissions
invariants
tests
resource limits
performance goals
security policies
acceptable failure modes

The coding agent and compiler could jointly decide how those requirements should be implemented.

For one workload, the result might be native machine code. For another, it might be WebAssembly. For another, it might be a database query plan, a GPU kernel, a serverless function, or a composition of existing services.

There may be no permanent source file corresponding to the implementation.

The durable artifact would be the intent and the evidence that the implementation satisfies it.

This suggests a progression in three stages.

Stage one: Agents write human programming languages

This is where we are now. Agents produce code that looks like something a human developer could have written.

Stage two: Agents write machine-oriented intermediate representations

Humans primarily review behavior, tests, specifications, generated explanations, and changes in capabilities. The underlying implementation becomes less important to routine review.

Stage three: Agents generate executable systems directly

The source of truth becomes a collection of intent, policies, interfaces, constraints, and verification evidence. The agent generates and regenerates executable implementations as needed.

At that point, asking which programming language an application is “written in” may stop making much sense.

Human-readable does not mean human-auditable

The strongest argument against this future is that source code is not only used for writing software.

It is also used for debugging, auditing, governance, security review, maintenance, and accountability.

We cannot safely operate important systems whose behavior nobody can inspect.

But readable source code is already a weak substitute for actual understanding. A large modern application may contain millions of lines of first-party code and depend on millions more through packages, generated files, cloud services, operating systems, and firmware. Almost nobody understands the entire system.

Code can be readable without the system being comprehensible.

An agent-native system would need to provide stronger forms of inspection than a pile of source files. It could generate:

explanations of specific behaviors
maps of data movement
proofs of important properties
permission and capability reports
dependency histories
simulations of proposed changes
executable tests
records of why each decision was made
human-readable implementations when necessary

The goal should not be to preserve readable code at all costs.

The goal should be to preserve human control.

Those are not the same thing.

The environmental cost of human-friendly code

There is another reason agents may eventually move beyond today’s programming languages: energy.

A widely cited 2017 study of energy efficiency across 27 programming languages compared runtime, memory use, and energy consumption across ten benchmark problems.

In its normalized results, Python consumed roughly 76 times as much energy as C and required roughly 72 times as much execution time. Python ranked near the bottom of the tested languages for energy efficiency.

This result has often been simplified into the claim that Python is one of the worst programming languages for the environment.

The reality is more complicated.

A 2024 reanalysis of programming-language energy efficiency found that these comparisons can conflate the language with its implementation, the quality of the benchmark program, the number of active processor cores, library behavior, memory activity, and other execution details.

After controlling for those factors, the researchers concluded that the programming-language implementation did not have a significant effect on energy consumption beyond execution time.

The central issue was not that the syntax of one language somehow consumed more electricity. Slower programs generally used more total energy because the hardware remained active longer.

That distinction does not make the problem disappear.

Standard Python is often much slower than optimized compiled code for computationally intensive work. A program that takes dramatically longer to perform the same job may consume dramatically more energy, even if the underlying processor draws power at a similar rate while executing it.

The good news is that the inefficiency is not unavoidable.

A 2025 study of compiled Python implementations compared CPython with several compilation and optimization systems, including PyPy, Numba, Codon, Cython, Nuitka, Mypyc, and Pyston-lite.

The researchers found that compilation could significantly improve execution time, memory use, and energy consumption. Codon, PyPy, and Numba produced speed and energy improvements of more than 90 percent on some of the tested workloads.

The more accurate conclusion is not that Python is inherently environmentally destructive.

It is that humans have often chosen programming languages based on human productivity while treating execution efficiency as a secondary concern.

Python is successful because it is readable, expressive, forgiving, and supported by an enormous ecosystem. In many organizations, saving developer time is worth spending additional computing time.

Agents do not face the same tradeoff.

A coding agent does not need friendly syntax to remain productive. It does not need a language that is easy to teach, type, or remember. It could generate a representation selected for the specific workload, compile it for the available hardware, measure the result, and replace it when a more efficient implementation becomes available.

Energy consumption could become a first-class property of programming rather than an optimization attempted after the software has already been written.

That matters because agents are not simply going to replace human-written code one line at a time. They are likely to increase the total volume of software produced and executed.

Agents can generate dozens of implementations, run thousands of tests, create disposable programs for individual tasks, and continuously regenerate working systems. Inefficiency that was tolerable when software was produced slowly by humans becomes more consequential when machines can generate nearly unlimited code.

The first agent-native language may therefore optimize for more than correctness and speed. It could consider:

total energy consumption
expected execution frequency
available processors and accelerators
memory movement
compilation cost
the carbon intensity of the available electricity
whether a workload can be delayed or relocated
whether an implementation will run once or billions of times

There may not be one universally optimal representation.

A one-time data conversion may favor minimal compilation overhead. A service expected to handle billions of requests may justify aggressive native optimization. A workload running on a battery-powered device may prioritize energy use over latency. A job operating in a data center could be scheduled around the availability of lower-carbon power.

An agent could make these decisions automatically.

Perhaps the environmental mistake would not be letting agents write unreadable code. It would be forcing them to keep writing Python simply because humans like reading it.

What becomes of the programmer?

None of this means humans stop building software.

It means our work moves upward.

Instead of spending most of our time describing implementation steps in a syntax designed for compilers, we will spend more time defining:

what the system should accomplish
what it must never do
which tradeoffs are acceptable
who can access what
how success is measured
how failures should be handled
what evidence is required before deployment

That is still programming.

In many ways, it is more directly programming than manually translating those decisions into loops, classes, functions, and configuration files.

The role of the programmer becomes less about producing source code and more about establishing intent, constraints, architecture, and judgment. It is another reason I keep coming back to the idea that taste is the bottleneck once the building itself gets cheap.

The difficult part of software development was never typing the syntax. The difficult part was deciding what should happen.

Agents are removing the translation layer.

Who will create it?

The first true agent-native language may not be introduced at a developer conference.

It may not have a clever name, a public specification, or a community debating its syntax.

It may emerge quietly inside an agent platform as a private intermediate representation used for planning, generating, verifying, optimizing, and compiling software. It may initially target conventional languages and existing toolchains, then gradually bypass more of them.

By the time humans recognize it as a programming language, agents may already be using it to write a meaningful portion of the world’s software.

The winner will not necessarily be the language humans enjoy reading most.

It will be the representation agents can use to produce the most reliable, secure, efficient, and verifiable systems while still giving humans meaningful control over the result.

Programming languages were invented so humans could tell computers what to do.

The next one may be invented so computers can tell themselves.

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.

How I Name the Things I Ship

Matt Senter — Sat, 01 Aug 2026 14:15:32 +0000

Naming a product feels like the smallest decision in the whole build. It is a word. You can change a word. And yet it is one of the few choices that follows the product everywhere it goes, onto the App Store, into the URL, out of a stranger's mouth when they try to tell a friend.

I have shipped enough small things now to have a rough method for it. It is not a branding framework. It is closer to a set of tests I run before I commit, so I do not end up defending a cute name for the next three years.

A name is the first promise

Before anyone opens your app, the name has already told them something. It sets an expectation, and the product either meets that expectation or spends its first thirty seconds correcting it. That is a bad trade. The best thing a name can do is get out of the way and let the thing be what it is.

So I try to make the name carry a little bit of the job. Not the whole pitch, just enough that when someone hears it and then sees what it does, the two click together instead of fighting. When a name and a product agree, the product feels inevitable. When they disagree, everything downstream, the copy, the icon, the first impression, has to work harder to paper over the gap.

The bar I actually use

I do not brainstorm a hundred options. I hold a candidate up against a short list of practical questions and see what survives:

Can I say it out loud once and have someone spell it back correctly?
Is it short enough to live in a menu bar, an icon label, and a sentence?
Can I actually get a usable domain and handle for it?
Does it point at the job, or at least not point away from it?
Will it still make sense if the product grows a little?

Most clever ideas die on the first two questions. A name you have to spell out letter by letter is a name that leaks users every time it gets spoken. A name nobody can search for is a name that makes you pay for every visitor twice. These are not glamorous constraints, but they are the ones that decide whether a name helps you or quietly taxes you forever.

Two families of names

When I look at what I have actually shipped, the names fall into two camps, and both are fine as long as you know which one you are choosing.

The first camp folds the job into the word. Premail reads as what it is: it works on your mail before the mail reaches you. Comoji is emoji you summon with a colon, and the name compresses that mechanic into something you can say. SeedMatrix is a grid of seed performance data, and the name says so. Even BeeReady, the nonprofit, leans on a phrase people already know so the mission is legible before you explain a thing. These names do a little work for free.

The second camp does not describe the job at all. It just wants to be short, sturdy, and easy to remember. Burly does not explain that it routes links to the right browser profile, and it does not need to. It is two easy syllables of personality that stick, with URL hiding in the middle of the word for anyone who notices. StockCar works the same way: it reads as fast and concrete before it reads as a stock briefing you listen to in the car, which is exactly what it is. A name like that carries little meaning on day one, so the product has to teach it. That is a fair deal when the word is memorable enough to be worth teaching, and a bonus when the meaning is sitting there waiting to be found.

The clever-name trap

The failure mode I have to talk myself out of most often is the pun only I fully get. There is a specific kind of naming high where you land on something layered and witty and feel briefly like a genius. Almost every time, that name is worse than the boring one sitting next to it.

The problem with a too-clever name is that the cleverness lives in your head, not the user's. They do not get the reference. They mishear it, misspell it, and cannot find it again. You end up explaining the joke, and a name you have to explain has already lost. I would rather have a plain name that works than a clever one I keep apologizing for.

Why this matters more now

It would be easy to treat naming as vanity, especially now that building is so cheap. But that is exactly why it matters more, not less. When AI lets anyone generate a competent app in an afternoon, the world fills up with competent apps. Being good is table stakes. Being findable, sayable, and memorable is one of the few edges left that a model will not hand you.

A generator can write the feature. It can even suggest a name. What it cannot do is know how the word will feel in your mouth, whether it fits the rest of what you have built, or whether you will still be proud to say it in a year. That judgment is the human part, and it is the same judgment I keep coming back to in this work: the building is cheap, and deciding is the job.

Name it once, and mean it

There is a tension in when to name. Name too early and you can fall in love with a word before you know what the product is, then bend the product to fit the name. Name too late and you ship something with a placeholder that never leaves. My compromise is simple: I do not lock a name until I can say what the product does in one sentence, and once I can, I try to name it and be done.

That rule doubles as a check on the product itself. If I cannot name the thing, it usually means I have not decided what the thing is yet. The struggle to name is often the product telling me its scope is still blurry. When the job is clear, the name tends to come easily, because there is finally something specific to point at.

And once it is named, I treat the name as settled. The name is the permalink, the handle, the word in someone's recommendation. Changing it later is not a rebrand, it is throwing away every bit of recognition you had started to earn. So I would rather spend the hour up front and then never touch it.

The short version

Before I commit to a name, I make it clear four hurdles:

Say it once. Can a stranger spell it back?
Search it. Does it lead to me, or to noise?
Match it. Does it agree with what the product actually does?
Keep it. Will I still want to say it out loud in a year?

None of this guarantees a great name. But it reliably kills the bad ones, and for a solo builder shipping small things, killing the bad ones is most of the battle. A name that is honest, sayable, and yours is worth more than a clever one, and it costs the same to choose. So I choose the honest one, and then I get back to building.

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.

Scope Creep in the Age of AI

Matt Senter — Thu, 30 Jul 2026 18:10:14 +0000

I have a new way to avoid the most important thing I should be doing: making the product better.

Not better in the way that gets it launched, finds a customer, or proves the idea. Better in a thousand tiny ways. Tighten the spacing. Rewrite the empty state. Add a keyboard shortcut. Tune the animation. Ask an AI coding agent for one more tasteful improvement, watch it appear a minute later, and immediately spot the next one.

Every tweak is fast. Every tweak feels productive. Together, they can keep me from the critical path for an astonishingly long time.

Scope creep used to come with friction

Scope creep is not new. Products have always accumulated requirements. The old version was just easier to see coming. A new feature meant a meeting, an estimate, a ticket, a developer, a test cycle, and another uncomfortable conversation about the deadline. The cost announced itself.

AI removed much of that friction. Now a new feature can begin with six words typed into a prompt. There may be no estimate and no one else in the room to ask whether it belongs. By the time I would have finished explaining the idea to a teammate, the first version is already running.

That is an incredible advantage. It is also a trap. When the cost of starting work feels like zero, the old instinct to stop and justify it never kicks in.

The dangerous phrase is “while I am here”

The pattern rarely starts with an obviously bad idea. It starts with something reasonable. While I am fixing this form, I should improve the validation. While I am in the validation code, I should add better error messages. The errors could use icons. The icons expose an inconsistency in the design system. Now I am reorganizing components that users have never complained about.

Each decision makes sense in isolation. That is what makes the pattern hard to resist. There is no single reckless choice to point at, only a chain of useful little choices that quietly carries the project somewhere it did not need to go.

The same thing happens outside the product. It is easy to spend an afternoon perfecting a logo, automating a report, reorganizing the CRM, or generating twenty versions of a landing page. The work may be good. It may even be necessary eventually. But if the business needs a customer conversation today, none of it is the job.

Cheap execution does not make attention cheap

AI lowered the cost of a tweak. It did not lower the cost of choosing the tweak, reviewing it, fitting it into the rest of the product, and carrying the added complexity afterward. Most of all, it did not make my attention infinite.

That is the cost I tend to miss. A two-minute change can open a twenty-minute branch in my thinking. It changes what I am looking at and what problem my brain is trying to solve. Do that fifty times and the day disappears, even if the agent wrote every line of code.

Speed makes this worse in a surprisingly pleasant way. Slow work creates natural stopping points. Fast work creates momentum. The instant reward of seeing each request completed makes the next request feel almost free, like pulling a slot-machine lever that always pays out in polished UI. I am not blocked or frustrated. I am having fun, which makes it harder to notice that I am off course.

Fun work and important work are not the same list

I love the building part. I suspect most builders do. It is concrete, responsive, and satisfying. You make a request and the thing changes in front of you. The critical path is often much less fun: decide what the product is, release it before it feels finished, ask someone to pay, hear what does not work, and choose what not to do.

AI widens the emotional gap between those two kinds of work. It makes the fun work even faster and more rewarding. It does not make an awkward sales conversation less awkward or a strategic choice less uncertain.

So staying focused now requires more than a backlog. It requires being honest about why I want to do the next thing. Is this the most important work, or is it the place where I get the quickest hit of visible progress?

I need a definition of done before I start

The most useful defense I have found is to define the finish line before the build gets interesting. What must be true for this version to ship? What question am I trying to answer? What is explicitly allowed to remain rough?

I keep the answers short. If the goal is “a stranger can download the app and complete the main task,” then a better settings screen is not on the critical path. If the goal is “find out whether anyone will pay,” then another week of product polish is probably a sophisticated way to avoid asking.

New ideas still get captured. They just do not get to appoint themselves urgent. I put them on a later list and return to the defined finish line. After the milestone is real, I can choose a deliberate polish pass and enjoy it without pretending it is something else.

Restraint is part of the craft now

I have written before that taste is the bottleneck when everyone can build. Restraint is one expression of that taste. It is not only knowing which version looks best. It is knowing that this problem does not need another version right now.

The ability to make almost anything quickly does not relieve me of prioritization. It makes prioritization more important. Every tool that removes an external constraint puts more weight on the internal one: the discipline to hold a direction, leave good ideas undone, and stop when the work has accomplished its purpose.

AI should shorten the distance between an idea and its outcome. If I let every satisfying tweak insert itself along the way, it does the opposite. The product gets more polished while the launch gets no closer.

The question I am trying to ask more often

Before I ask an agent for one more change, I am trying to pause and ask a less exciting question: what would move this product or business forward today?

Sometimes the answer really is the tweak. Details matter, and I do not want to ship careless work. But often the answer is to release the build, send the email, call the customer, write the offer, or make the decision I have been circling.

The age of AI gives builders extraordinary leverage. Using it well means knowing when to press the accelerator. It also means keeping a hand on the wheel.

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.

Why Most of My Apps Are Free, and One Is Not

Matt Senter — Sat, 25 Jul 2026 14:15:21 +0000

People sometimes ask why I give so much of my work away. StockCar is free on iOS with no paywall. Comoji is free. Burly is free. And then there is Premail, which has a price.

That is not an accident or a mood. Free is a decision I make on purpose, and so is charging. Here is how I think about which one a product gets.

Free is a distribution choice, not a generosity contest

When I ship a small utility for free, I am not being charitable. I am picking the fastest path to the only thing that matters early on: people actually using the thing. A price tag, even a small one, is a wall. For a tool that lives or dies on whether it fits into someone's day, the cost of that wall is usually higher than any revenue behind it.

Comoji is a good example. It adds colon emoji shortcuts to the apps you already type in. The whole pitch is that it disappears into your flow. Nobody is going to open their wallet to find out whether an autocomplete feels right. They will try it for thirty seconds and either keep it forever or forget it. Free is what lets that thirty seconds happen at all.

The kind of product decides the model, not the other way around

I have come to sort my own work into two rough shapes, and the shape tells me almost everything about pricing.

The first shape is a small, self-contained utility. It does one thing, it runs on your machine, and once you have it, it mostly just works. StockCar, Comoji, and Burly all live here. They cost me real effort to build, but very little to keep serving to one more person. When the marginal cost of another user is close to nothing, charging per user starts to feel like friction for its own sake.

The second shape is a product that keeps working on your behalf, continuously, in a way that carries an ongoing cost and delivers ongoing value. That is where a price stops being friction and starts being fair.

Why Premail is the one that charges

Premail is a privacy-first email app that filters spam, recruiters, and noise before they reach your inbox. It is not a one-and-done utility. It works every single day, on every message, in the background, quietly deciding what deserves your attention.

That is a different deal than a menu bar helper. The value compounds daily, and so does the work behind it. A product that earns its keep in your life every morning is exactly the kind of thing that should be able to fund its own future, so it can keep getting better instead of quietly rotting. So Premail has tiers:

a free tier, so the wall is never the reason someone does not try it
a Pro plan at nine dollars a month for people who want the full defense running all the time
a lifetime option at ninety-nine dollars for people who would rather pay once and be done

The free tier is there for the same reason all my other apps are free: to let people find out if it fits before anything is asked of them. The paid tiers exist because an inbox defended every day is worth paying for, and because a product I want to still be running in five years needs a reason to still be running in five years.

A studio can afford patience

None of this would work if every product had to pay for itself immediately. It works because these apps live under Senternet, which is part product lab and part consulting shop. The consulting side funds the patience the product side needs.

That structure is a quiet advantage. It means I do not have to slap a price on a tiny utility just to justify the weekend I spent building it. I can let StockCar, Comoji, and Burly be free because they do not have to carry the studio. They can just be good, spread on their own merits, and earn trust. The trust is the asset. It shows up later, in the products where a price makes sense and in the reputation that makes the next launch easier.

Free is not the same as cheap

I want to be careful about one thing. Free does not mean I put less into the free apps. If anything the opposite is true, because a free tool has to be good enough to keep on its own, without a subscription reminding you every month that you paid for it. There is no billing relationship holding a free app in place. It stays on your machine purely because it is worth the space.

So the bar for a free product is not lower. It is higher in a specific way: it has to be so genuinely useful that you would feel the absence if it were gone. That is a harder target than being worth nine dollars, and hitting it is the whole point.

The questions I actually ask

When I start something new, the pricing question is not the first one, but it is not far behind. A few things I ask before deciding:

Does this do its job once, or does it keep working for you every day?
What does one more user actually cost me to serve?
Would a price help this spread, or is it just a wall in front of a good first impression?
If this has to earn its keep to survive, is the value big enough that charging feels fair rather than grabby?

Most of my utilities answer those questions the same way, which is why most of them are free. Premail answers them differently, which is why it is not. The model is not a branding decision or a growth hack. It is just an honest reading of what the product is and what it is worth. Get that reading right and the price, or the absence of one, mostly picks itself.

Why I Built Burly

Matt Senter — Fri, 24 Jul 2026 14:15:27 +0000

I run more than one browser, and more than one profile inside each of them. Safari for work and personal. Chrome with a dev profile separate from everything else. It is how I keep the contexts of a day from bleeding into each other.

The trouble is that the moment I click a link, the operating system stops caring about any of that. It hands the URL to whatever browser happens to be the default and walks away.

So I built Burly, a tiny macOS app that puts that decision back in my hands.

I have spent most of my career building software, and the projects that stick with me are almost always the ones that started as a personal annoyance I refused to keep tolerating.

Burly is exactly that.

It did not come from a market analysis or a roadmap. It came from the small, daily friction of clicking a work link from Slack and watching it open in my personal browser, logged into the wrong account, next to the wrong tabs.

The annoyance was tiny and constant

No single instance of this problem is a big deal. A link opens in the wrong place, you notice, you drag the tab over or copy the URL and paste it into the right window.

Ten seconds, maybe.

But you do it dozens of times a day, and the cost is not really the ten seconds. It is the interruption. You were reading something, and now you are doing tab logistics instead. The contexts you worked so hard to keep separate collapse into each other anyway.

I kept waiting for the friction to feel small enough to ignore. It never did. It just quietly taxed every link I clicked.

The tool I wanted did not quite exist

There are apps that let you set rules: send anything from this domain to that browser. I tried that approach and it never fit how I actually work.

My routing is not really about the domain. The same link might belong in my work profile in one moment and my personal profile in another, depending on what I am doing. A rule engine forces me to predict that in advance, and to maintain the rules forever as my life changes.

What I wanted was simpler and more honest: at the instant a link arrives, just ask me where it should go, and make answering instant.

So that is what Burly does.

How it works

Burly becomes the system handler for the links you click. When you open one, a fast radial picker appears and you choose the destination with the keyboard: Safari Work, Chrome Dev, whatever profiles you keep.

It discovers your browsers and profiles automatically and keeps that list live, so I never have to configure anything by hand. It works across Safari, Chrome, Brave, Edge, Vivaldi, Arc, and the Firefox family.

And because being asked every single time would become its own annoyance, there is a modifier key that skips the picker and reopens your last-used destination. Most of my links follow a streak: several to work, then several to personal. The bypass makes the common case free and saves the choice for when it actually matters.

Keyboard-first, because speed is the whole point

A router that routes links slowly is worse than no router at all. If the picker took even a beat too long to appear, or if it forced me to reach for the mouse, I would stop using it and go back to dragging tabs.

So the picker shows up the instant a link arrives, and every choice is a keystroke away. That constraint drove more of the design than any feature did. The bar was simple: Burly had to be faster than the habit it was replacing, or it did not deserve to exist.

Private by default, like everything I ship

A tool that sees every link you click has to be trustworthy, so Burly keeps everything on the Mac. There is no account, no cloud, and no analytics, and no URL ever leaves the device. It is a native menu bar app, signed and notarized.

This is the same instinct behind the other small tools I make. The links you open are some of the most revealing data about your day. The right move is not to protect that data carefully. It is to never collect it in the first place. Data you never gather is data you can never leak.

Why a problem this small was worth solving

It would be easy to dismiss Burly as trivial. It routes links. That is the entire pitch.

But I have come to believe the small, constant frictions are exactly the ones worth removing, precisely because they are constant. A big problem you hit once a month gets your full attention and a real workaround. A tiny problem you hit forty times a day never rises to the level where you stop to fix it. It just wears a groove into your attention.

AI has made it cheap enough to build a small native app that fixing these little grooves is finally worth an afternoon. That changes the math on what deserves to exist. A tool does not have to be ambitious to be worth building. It just has to remove something you were tired of tolerating.

The test I keep applying

Burly passed the only test I really trust for a personal tool: I reached for it the next day without thinking, and the friction it replaced was simply gone.

I built it for myself, and it turned out other people run their browsers the same anxious, context-separated way I do. That is usually how it goes. Scratch a specific enough itch and you find out you were never the only one scratching it.

Every link, in the right browser profile. It is a small promise, and keeping it well is the whole product.

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.

Rebuilding SeedMatrix, the Company I Co-Founded in 2008

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

Most of what I write about here is new: apps I started this year, tools that did not exist a decade ago. This one is different. I am back inside a company I helped start in 2008.

It is called SeedMatrix, and I am rebuilding its engine now through Senternet. Returning to an eighteen-year-old product has taught me more about what is worth building than any greenfield project has.

The problem that would not go away

SeedMatrix exists to answer one deceptively simple question a farmer asks every year: will this variety actually perform on my field? A seed brand can say its variety yields well. Proving it in that grower's county, on that soil, under that irrigation, against the variety they planted last season is a completely different problem.

The data that would settle it exists, but it is scattered across dozens of independent trial networks, each with its own format and its own corner of the country. SeedMatrix pulls that official variety trial data together with a company's own plot results and lets a sales team slice it down to the conditions of the field in front of them.

When I look at what that has grown into, the numbers say something about how real the problem is: more than 1.8 million trial data points, twelve crops, forty states and provinces. That is not a problem I invented. It is one that was here before me and will outlast me, because a grower makes this bet once a season with a whole year riding on it.

Why I came back to it

I could have left SeedMatrix in the past and pointed only forward at the newer things. Plenty of founders treat old work that way, as a closed chapter. I do not see it like that anymore.

A problem that is still unsolved eighteen years later is not a stale problem. It is a durable one. The consumer apps I build now, like StockCar, solve real annoyances, but the annoyance and the fix can both shift quickly. Agriculture moves on a slower, deeper clock. The question of which seed to plant where has been asked every spring for as long as there have been farms, and it will keep being asked.

So coming back was not nostalgia. It was recognizing that some problems are worth a second pass precisely because they never expired. The first version proved the problem was real. The rebuild is a chance to solve it the way I would if I were starting today.

What eighteen years changes about a rebuild

The problem is the same. Almost everything around it is not. When SeedMatrix started, building a platform that could ingest scattered trial data, normalize it, and turn it into head-to-head comparisons took a team and a long runway.

Doing that rebuild now, with AI accelerating the parts that used to eat months, is a different exercise. One builder can move through the boring, structural work at a pace that used to require several. The engine that turns 1.8 million raw data points into a comparison a grower trusts is exactly the kind of unglamorous, high-leverage machinery that AI-assisted development is genuinely good at helping one person carry.

That is the quiet story of this rebuild. The ambition did not change. The size of the team needed to reach it did. Returning to old work is one of the clearest ways I have found to feel how much the tools have shifted, because I am measuring the new version against a baseline I lived through.

Rebuilding is not the same as restarting

There is a temptation, coming back to something this old, to throw all of it away and begin from a blank page. I have learned to resist that. The valuable part of SeedMatrix was never the code. It was the understanding of the problem, earned the slow way.

Knowing, for example, that:

every data point has to tie back to a named, dated, independent trial or a skeptical grower will not believe it
the same variety can look great in one county and mediocre in the next, so filtering by region, soil, irrigation, and maturity is not a feature, it is the point
a sales rep needs the answer fast enough to have the conversation in a truck cab, not back at a desk
seed is a high-trust purchase, so the data has to be defensible, not just persuasive

None of that shows up in a code diff. It is the part that took years to learn and cannot be regenerated. A rebuild done right keeps the hard-won understanding and replaces only the machinery underneath it. Throwing everything out would have meant paying tuition on the same lessons twice.

The through line I did not expect

I build consumer tools that run on your own machine with no account, and I also work on a B2B agtech platform that aggregates data at scale. On the surface those could not be more different. Under the surface they rhyme.

Both are about trust. Comoji earns it by never letting your typing leave your Mac. SeedMatrix earns it by making every number traceable to an independent source a grower can check. In each case the product only works if the person on the other side believes it, and belief is built the same way everywhere: by being honest about where the data comes from and what happens to it.

I did not plan for a farm-data platform and an emoji autocomplete to teach the same lesson. But returning to SeedMatrix surfaced it. The domain changes. The reason people let your software into their day does not.

What I am taking from the round trip

Going back to a company I co-founded in 2008 has reshaped how I judge a new idea. A few questions I now ask before starting anything:

Is this problem durable, or does it disappear the moment fashion moves?
If I looked at this again in eighteen years, would it still be worth solving?
What understanding, not code, is the real asset here?
Could one person, with today's leverage, carry what once needed a team?

SeedMatrix answers yes to all of them, which is why the rebuild is worth my time. The problem endured, the understanding compounded, and the tools finally caught up to the ambition. Sometimes the most forward-looking thing you can do is go back and finish something the way it deserved to be built in the first place.

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.