DEV Community: Matt Senter

Your AI Coworker Might Be More Honest Than Your Human One

Matt Senter — Thu, 27 Aug 2026 00:57:16 +0000

An AI agent surfacing its uncertainty is not a personality quirk. It is a useful work habit.

I see people make fun of Claude Code’s “honest answer” replies all the time. You know the kind: “Honest answer: I didn’t actually verify that.” “Honest answer: I took a shortcut.” “Honest answer: the documentation is incomplete and I was relying on memory.”

It has become enough of a trope that people share screenshots for laughs. And to be fair, Claude can overdo it. There is something funny about a machine dramatically confessing that it skipped a step. But I think we are laughing at the wrong thing.

Imagine a coworker saying the same thing

Imagine a human employee giving you that level of disclosure voluntarily: “I pushed this without fully testing it.” “I ignored the normal process because I thought I could get it out faster.” “I said this was done, but I only tested the happy path.” “I am not actually sure that assumption is correct.” “I cut a corner here and should probably go back and fix it.”

How often does that happen without someone first being cornered? Most people are not malicious. They are human. We are wired to protect ourselves, avoid embarrassment, and present our work in the best possible light. If something ships and seems to work, there is a strong incentive not to volunteer every shortcut, uncertainty, or questionable decision that happened along the way.

In software especially, I would bet there is an enormous amount of production code running today because someone quietly bent a rule, skipped a test, misunderstood a requirement, or decided “good enough” was good enough. Most of those stories never get documented unless something eventually breaks.

The phrase is not the point

So when Claude Code says, “Honest answer: I didn’t verify that,” my reaction is increasingly: good. That is exactly the kind of behavior I want from an AI agent. The phrase itself does not magically make the next sentence true. AI systems can still misunderstand what they did, hallucinate explanations, or confidently describe their own behavior incorrectly.

The useful part is the norm behind it. I want agents to tell me what they verified, what they assumed, what they skipped, where they took shortcuts, and how confident they are in the result. I want them to distinguish between “I know this works” and “I think this works.” I want them to admit when they took the fastest path instead of the safest one.

Transparency is part of the job

As AI agents take on more real work, that kind of operational transparency may become one of their biggest advantages. It gives the person responsible for the outcome a clearer choice: accept the tradeoff, ask for more verification, or stop the work before an assumption becomes an incident.

We spend a lot of time asking whether AI can behave more like a good human employee. Maybe this is one case where the humans should take notes from the AI. A trustworthy coworker is not someone who never makes a mistake. It is someone who makes the uncertainty visible while there is still time to do something about it.

I’m Trying to Talk Myself Out of Buying a Mac Studio. Apple Isn’t Helping.

Matt Senter — Wed, 26 Aug 2026 13:52:43 +0000

I’m trying to convince myself that I do not need a fully loaded Mac Studio.

It is not going well.

Apple’s new Mac Studio is a ridiculous desktop: up to 512GB of unified memory and 1.2 TB/s of memory bandwidth. More importantly, Apple is explicitly presenting it as an on-device AI machine, capable of running large open-weight models locally. Apple says as much.

I absolutely do not need this computer. Probably. The problem is that machines like this are starting to look less like desktops and more like privately owned AI infrastructure that happens to sit on a desk.

Apple is practically advertising a private AI server

Apple is not being subtle about where it thinks this goes. Its Mac mini announcement describes the machine as suitable for always-on, deskside agentic computing. The Mac Studio takes that idea much further: huge unified memory, high bandwidth, and the ability to cluster machines over Thunderbolt 5 for very large local workloads. That is Apple’s framing, not mine.

Unified memory is the unusually interesting part. On Apple Silicon, the CPU and GPU draw from one shared memory pool instead of shuffling work between system memory and separate GPU VRAM. Apple’s open-source MLX framework is designed around that architecture.

This does not magically make a Mac Studio equivalent to a data center full of NVIDIA hardware. But it does make hundreds of gigabytes of GPU-accessible memory possible in a quiet personal computer. That changes the category of work the machine can plausibly handle at home.

The interesting architecture is local-first, not local-only

The thesis is not that a Mac Studio replaces OpenAI, Anthropic, or Google. The frontier labs will continue to have more compute, faster release cycles, and better models for plenty of difficult work.

The more interesting idea is a private local intelligence layer that handles everyday work, keeps sensitive context home, and escalates only the hardest problems to a frontier model.

An orchestrator should not merely ask which model is smartest. It should consider whether a task is sensitive, how difficult it appears, whether it needs code or vision, how quickly it needs an answer, what an external call costs, and whether a local model is good enough.

Orgabot is the clearest example

I already run several products where AI is central to the architecture: Orgabot, Premail, and Highwire. Orgabot is the most obvious candidate because an orchestration system should not be married to one model.

                         ORGABOT
                            |
          +-----------------+------------------+
          |                 |                  |
          v                 v                  v
      FAST LOCAL       SPECIALIST LOCAL    FRONTIER CLOUD
       MODELS               MODELS              MODELS
          |                 |                  |
     classification      coding             GPT
     extraction          vision             Claude
     summarization       images             Gemini
     embeddings          speech             etc.
          |                 |
          +--------+--------+
                   |
             PRIVATE DATA
             STAYS LOCAL

A small local model can classify, extract, summarize, route, and create embeddings. A stronger local coding model can handle ordinary software work. Other local models can specialize in vision, speech, or image generation. A genuinely difficult task can be escalated to whichever frontier model is strongest at the time.

That makes model choice infrastructure instead of a recurring user decision. It also makes the cloud a specialist rather than the default employee.

Premail makes the privacy case

Premail is already BYOK and privacy-first. It can use the provider and model a person chooses, including local models served through Ollama. A powerful always-on Mac would make that design much more compelling.

Email could be indexed locally, embedded locally, classified locally, summarized locally, and processed by a model running a few feet away. Routine drafts and analysis would not have to leave the house at all.

That matters because an inbox contains financial records, health information, family conversations, account data, contracts, receipts, attachments, and years of personal history. The more context an AI email assistant has, the more useful it becomes, but the more consequential it is to transmit that context elsewhere.

With a local-first design, the default reverses. The raw mailbox stays home. A frontier model can still help when it is warranted, but only with the minimum context necessary.

Highwire could move expensive inference into my house

Highwire relies on AI to ingest news, group articles into stories and narratives, analyze framing and evidence, and generate summaries before readers see the result. It is natural to assume all of that work belongs in the cloud because the public website does.

Those two things do not actually have to be coupled.

Internet sources
      |
      v
Private AI infrastructure
in my house
      |
      | analysis, classification, embeddings, summarization
      v
Finished structured result
      |
      v
Cloud production environment
      |
      v
highwire.news

The public site needs reliable hosting, storage, networking, and distribution. That does not mean every expensive inference job must run in a cloud data center. A local worker could perform much of the analysis, then publish structured results to production.

There are real tradeoffs: queues, retries, remote administration, monitoring, backups, and a graceful cloud fallback. But this is not the same as hosting a public website from my house. A processing job running ten minutes late is usually survivable.

Local coding is already remarkably good

One of the most interesting local coding candidates is Qwen3-Coder. The family is designed for agentic coding and tool-driven workflows, which is precisely the kind of work I could imagine Orgabot assigning to a local model.

It does not need to replace the best cloud model on every task. It needs to handle a large share of routine work without sending a repository to someone else’s infrastructure or charging for every token generated.

The caveat is important. Local models can lag the frontier in release cadence, long-horizon reasoning, tool use, and recovery from difficult failures. I would not want to be fully offline when a problem is ambiguous, architectural, or unusually stubborn.

That is an argument for escalation, not an argument against local models.

The frontier should become an escalation path

Most AI work does not require the smartest model humanity has produced. I do not need the latest frontier model to determine whether an email is a receipt, extract a date, create an embedding, summarize a Git diff, classify a news article, transcribe audio, inspect a straightforward log file, or make hundreds of small decisions during a day.

Task arrives
    |
    v
Can a local model handle it confidently?
    |
   YES ------------------> Run locally
    |
    NO
    v
Does it contain sensitive information?
    |
   YES
    |
    v
Reduce, sanitize, or preprocess locally
    |
    v
Send minimum necessary context
    |
    v
Frontier model

When Orgabot encounters the race condition that has survived three attempts at a fix, needs to reason through a major migration, or simply has low confidence, it can call the frontier model. That is a much more realistic future than pretending every machine should be independent of the cloud.

Privacy may be the strongest reason to do this

Apple has invested heavily in privacy-preserving cloud inference through Private Cloud Compute. The engineering is impressive. But there is still an architectural difference between building a more private cloud and never sending sensitive data to the cloud in the first place.

The most private cloud inference request is the one I never make.

That applies to Premail, but also to source code, internal business documents, unreleased products, personal files, credentials, and the large amount of context an autonomous system can accumulate. Local AI reduces the number of parties I have to trust.

It does not eliminate risk. A local machine still needs patching, encryption, backups, isolation, and monitoring. But removing an external network request removes an entire category of exposure.

The economics get weird surprisingly fast

For someone who occasionally asks a chatbot questions, buying expensive local AI hardware makes little economic sense. Cloud subscriptions are convenient and someone else maintains the GPUs.

Agentic workloads change the equation. A system continuously inspecting repositories, reading logs, evaluating tasks, summarizing information, monitoring systems, and deciding what to do next can consume an enormous number of tokens. A local model moves the marginal cost of another request closer to electricity.

It is still not free. Buying a Mac Studio prepays for compute through capital cost, power, depreciation, storage, maintenance, and eventual replacement. For occasional requests, cloud APIs probably win. For an orchestrator making thousands of decisions continuously, owning some inference starts looking much more interesting.

I probably do not need the 512GB model

This is where I am still attempting restraint. A 512GB Mac Studio is an almost comical amount of memory for a personal computer, but most of the workloads I am describing do not require it.

The rational version of this experiment is probably a 128GB or 256GB machine with a carefully chosen set of models. The irrational version is 512GB because someday I might want to see what enormous model I can fit into it.

I am unfortunately aware of which version of myself usually wins these debates.

Apple has not been helpful

For the first few years of generative AI, we rented intelligence from somebody else’s data center. Machines like the Mac Studio suggest a different future: own enough intelligence locally to handle everyday work, and rent frontier intelligence only when you actually need it.

If I think of the Mac Studio as a powerful desktop computer, buying a maxed-out one seems ridiculous. If I think of it as infrastructure that can run Orgabot continuously, privately process Premail data, generate images, transcribe audio, operate coding agents, help produce Highwire, and selectively call frontier models when necessary, the calculation looks different.

Which is unfortunate. I started researching this specifically to give myself reasons not to buy one.

Microsoft’s Account Recovery Is Security Theater

Matt Senter — Tue, 25 Aug 2026 15:19:47 +0000

My son’s Microsoft account was hijacked a couple of weeks ago, and I have spent an unreasonable amount of time since then trying to convince Microsoft to give it back.

I know the Microsoft account ID. I control the email address used as that ID. My son is a child in my Microsoft Family Safety account, where I am the organizer. I have the computer he used, his previous password, his device IDs, his historical Family Safety reports, screenshots showing the account before and after it was compromised, and the IP address from which he normally used it.

Microsoft still will not recover the account.

The problem is not that Microsoft lacks evidence. The problem is that Microsoft’s recovery system does not seem capable of reasoning about evidence that falls outside its script. That is where security stops being security and becomes theater.

How the account was hijacked

For privacy, let’s say my son’s Microsoft account is myson123@icloud.com.

We are not certain exactly how the compromise occurred, but we believe it may have originated with a scam on Discord, where my tweenage son talks with friends about Minecraft and other games.

At some point, an attacker gained access to his Microsoft account and replaced its recovery information. Now, when we attempt to recover the account, Microsoft wants to send the verification code to br***@securitylock24hrs.net.

That is not our email address. It belongs to the attacker. The particularly strange part is thatmyson123@icloud.com remains the Microsoft account’s sign-in identity. We control that iCloud account. The attacker does not. Yet Microsoft will not simply send a verification message there.

Instead, Microsoft’s account recovery system insists on communicating through the security information that the attacker changed. The attacker compromises the account, changes the recovery address, and Microsoft then treats the attacker’s recovery address as more authoritative than the original email address still associated with the account.

That is a pretty good arrangement for the attacker.

This appears to be a known attack pattern

After seeing securitylock24hrs.net, I searched for the domain and immediately found other people reporting Microsoft accounts compromised with recovery addresses at the exact same domain. Several Microsoft Q&A threads from 2026 describe users suddenly seeing unfamiliar@securitylock24hrs.net addresses after account compromises. One victim specifically described the compromise happening after a verification process associated with a Minecraft Discord server.

See: Microsoft Q&A: securitylock24hrs.net

There is a recognizable pattern:

The original account owner loses access.
The security information gets changed.
A recovery address at securitylock24hrs.net appears.
The legitimate owner is unable to use normal recovery methods.

That should be a signal. Instead, Microsoft’s recovery system treats the attacker’s newly added address as authoritative.

Welcome to the recovery maze

Microsoft does have an account recovery process. In fact, it has several, which is part of the problem. The normal recovery form asks you to prove ownership by supplying information about the account. Microsoft says the form intentionally asks questions that only the account owner should know and recommends submitting it from a previously used device and location.

See: Microsoft Support: Help with the Microsoft account recovery form

That sounds reasonable until you consider that this is a child’s account. My son has never purchased anything through this Microsoft account, so there is no useful credit card history. He does not use Outlook for email, so there are no message subject lines or contacts to identify. He does not use Xbox. He is a kid who uses a Microsoft account primarily because Windows and Minecraft want him to have one.

Nevertheless, during the recovery process I have been asked for all of the following:

ACSR number: I have submitted the recovery form four times and have never received one. The recovery process asks for an identifier its own recovery process has failed to provide.
Contact email, phone number, IP address, country, state, and ZIP code: Provided. Apparently not sufficient.
Payment information and proof of purchase: There is none. He is a child and has never purchased anything through this account.
Child’s name and date of birth: I supplied his real name, nickname, and online handle. I do not know what date was entered years ago, and I cannot simply view or verify it through Family Safety.
Xbox information: None. He does not have an Xbox associated with the account.
Account creation date, last login, and last password change: Estimated, because Microsoft knows this history and I cannot find it in Family Safety.
Windows Device ID: I found the identifier Microsoft directed me to inside a JSON file and supplied it. I also supplied the more prominent device ID available in Windows settings. Still not enough.

At some point, you have to ask what the purpose of collecting all of this information actually is if none of it can move the process forward.

Microsoft already knows I am his parent

My son’s account is a child account inside my Microsoft Family Safety family, and I am the organizer. Microsoft describes Family organizers as the administrators of family groups. Organizers can manage permissions, screen time, content filters, spending, consent, and activity reporting.

See: Microsoft Support: Set up Microsoft Family Safety

I continue to receive weekly Microsoft Family Safety emails about my son’s account. I sent Microsoft those reports, including reports from before and after the compromise. I showed them my own Microsoft account and its relationship to his. I showed them the Windows computer attached to the account. That computer now repeatedly asks my son to sign back into Microsoft Family Safety, but he cannot because his Microsoft account was hijacked.

Microsoft trusts me enough to supervise the child, approve purchases, restrict apps, monitor activity, and manage his digital life, but it does not trust me enough to help recover his account. Family Safety gives me no way to reset the child’s Microsoft account. If Microsoft is going to maintain a verified parent-child relationship, account recovery is one of the most important situations in which that relationship should matter.

Why doesn’t Microsoft just email the iCloud address?

There is a legitimate security argument here. Microsoft distinguishes between an account’s sign-in identity and its designated security information. An email address used to sign into a Microsoft account is not automatically treated as sufficient proof that the person controlling that mailbox owns the Microsoft account.

At first glance, that seems reasonable. You do not want someone to gain control of an external mailbox and automatically use that to seize a Microsoft account too. But Microsoft is already trusting an external mailbox as part of the recovery process. When Microsoft sends a recovery code to a designated recovery email address, it is relying on another email provider to authenticate the person receiving that message.

I am not arguing that control of myson123@icloud.com should automatically authorize a password reset in every case. I am arguing that it is powerful evidence, especially when combined with everything else Microsoft already knows. In our case, Microsoft has all of these signals:

The original iCloud address associated with the Microsoft account and our continued control of it.
A previous Microsoft password, a known Windows device, and multiple device identifiers.
The parent account linked through Microsoft Family Safety and years of activity reports.
The normal household IP address, geographic information, and screenshots before and after the compromise.
A recovery address using a domain publicly associated with other Microsoft account compromises.

The sensible security response is not that the iCloud account proves everything. It is that the iCloud account is one strong signal among many, and the newly changed recovery address should no longer be treated as unquestionable ground truth.

Security systems need an escape hatch for reality

The Microsoft support team appears to be following a script. I do not blame an individual support person for doing that. They probably are not permitted to deviate from it. The problem is the script.

Microsoft seems to have designed account recovery primarily around preventing social engineering attacks against Microsoft. That is understandable. If support agents could freely reset accounts, attackers would bombard them with fake recovery requests. So Microsoft locked the process down, removed discretion from support representatives, and automated much of the verification.

That makes the process difficult to exploit through customer support. But Microsoft has another threat model to consider: what happens when the attacker is already inside? The attacker gets into the account once and changes the security information. From that moment forward, Microsoft’s architecture begins treating information supplied by the attacker as part of the account’s trusted state. Meanwhile, the legitimate owner has to reconstruct years of obscure metadata to satisfy an automated recovery system.

For a lightly used child’s account, much of that metadata does not even exist. The attacker has to fool the system once. The victim has to prove ownership over and over again.

There are obvious ways Microsoft could improve this

Make Family Safety useful for recovery. A verified parent-child relationship should be a major recovery signal, with an organizer-authenticated workflow.
Preserve and use historical security information. If a longstanding external email disappears immediately before an account takeover, a fraud investigator should be able to see that history.
Detect known malicious recovery domains. A domain repeatedly associated with account takeovers should trigger additional scrutiny, not look like an ordinary account update.
Create an actual escalation path. Not another form, chatbot, or representative who cannot act. Someone should be able to review the complete account history and make a judgment based on the totality of the evidence.

Why I reported the domain to Cloudflare

I also reported securitylock24hrs.net to Cloudflare. I was not asking Cloudflare to recover the Microsoft account. I was reporting infrastructure being used by the attacker. If a domain is being used as part of an account-takeover operation, reporting it to the companies that provide network services for that domain can help get the abuse investigated, disrupted, or forwarded to the appropriate provider.

Cloudflare’s abuse reporting system automatically rejected my submission, apparently because the system was overloaded. I also filed a report with the FBI’s Internet Crime Complaint Center, IC3, and gave Microsoft that report as additional documentation that I was formally asserting the account had been stolen. I still do not have my son’s account back.

The frustrating part is that this should be solvable

I am not asking Microsoft to take my word for anything. Challenge the iCloud account. Challenge my Microsoft account. Challenge the Windows device. Compare IP history. Look at Family Safety history, the timing of the security-information change, the attacker’s recovery domain, and the previous password. Look at all of it together.

That is what a security investigation is supposed to do. Instead, Microsoft’s process seems to ask whether I can fill enough predetermined boxes with exactly the information its automated system expects. Those are not the same thing.

Real security is about evaluating risk and evidence. Performative security is about following the procedure. Right now, Microsoft’s account recovery process feels much more like the latter. For this child’s account, it appears to have been easier for someone on Discord to steal the account than it is for his parent to get it back. That is not a successful security model. It is a security model that, once compromised, protects the attacker.

The Internet Is Becoming Agent-First: From Fighting Bots to Empowering AI Agents

Matt Senter — Mon, 24 Aug 2026 12:53:04 +0000

The web was built for humans, hardened against machines, and is now being rebuilt for machines acting on our behalf.

For most of the commercial internet’s history, a bot was something to stop.

We put CAPTCHAs in front of forms. We fingerprinted browsers, scored behavior, throttled requests, challenged unfamiliar devices, and blocked entire ranges of IP addresses. We built an enormous security industry around answering one question:

Is this a real person?

Now, almost overnight, we are asking the opposite question.

How do we let a machine book the trip, compare the insurance plans, buy the groceries, reschedule the meeting, file the expense report, and operate the software on a person’s behalf?

The internet is not simply becoming more automated. It is becoming agent-first. Machines are no longer only crawling pages in the background. They are becoming users, customers, negotiators, and representatives.

That change promises a much more convenient internet. It also forces us to revisit nearly every assumption we made while defending the last one.

The web was never human-only

The early web depended on automation.

Search crawlers made pages discoverable. RSS readers collected updates. Monitoring tools checked whether sites were online. Accessibility tools transformed content into forms people could use. Archival bots preserved pages that would otherwise disappear.

The original Robots Exclusion Protocol was created in 1994 as a lightweight agreement between website owners and automated crawlers. A site could publish preferences in a robots.txt file, and a well-behaved bot could choose to respect them.

It was a social contract, not a security boundary.

The commercial web changed the incentives. Automation became a way to scrape proprietary data, stuff stolen credentials, create fake accounts, scalp scarce inventory, send spam, commit ad fraud, and overwhelm systems. A bot could perform the same action as a person, but faster, cheaper, and millions of times.

So the working assumption hardened:

Humans are legitimate. Machines are suspicious.

That assumption was never completely accurate. Plenty of humans behave badly, and plenty of bots are useful. But it was simple enough to build defenses around.

Agentic software breaks that shortcut.

A bot can now be the customer

An AI agent may arrive at a site through a browser, click the same buttons a person would, and use the same account. The traffic is automated, but the intent belongs to a real customer.

Products such as ChatGPT agent made this concrete: an agent can navigate websites, use connected data, fill out forms, conduct research, and pause for approval before consequential actions. Similar capabilities are spreading through browsers, operating systems, workplace tools, and commerce platforms.

To the website, this can look uncomfortably similar to the automation it spent decades blocking. The difference is not whether software performed the action. The difference is whose interests the software represents, what authority it has, and whether the site can verify either one.

Blocking all machines will increasingly mean blocking customers. Allowing all machines would be reckless. The old human-versus-bot test is becoming the wrong abstraction.

The new question is:

Which agent is this, who authorized it, and what is it allowed to do?

The agent-first stack is already taking shape

Today’s agents often use a visual browser because that is the one interface nearly every service already exposes. It is a clever compatibility layer, but it is also a brittle one. Buttons move. Labels change. Popups appear. A workflow designed for a person may require an agent to interpret screenshots, imitate clicks, and hope the state changed as expected.

Agent-first applications expose capabilities directly instead of forcing machines to pretend to be people. Several initiatives are filling in different layers of that future.

MCP connects agents to tools and data

Anthropic introduced the Model Context Protocol as a standard way for AI applications to connect to external data and tools. Instead of building a custom integration for every pairing of assistant and service, a developer can expose a consistent interface that multiple agent systems understand.

MCP is less like a new website and more like a standardized service port beside the website. The human interface can remain, while agents get a structured way to search, read, create, or update information.

A2A lets agents work with other agents

Google launched the open Agent2Agent Protocol so independently built agents can advertise capabilities, exchange messages, coordinate tasks, and return artifacts. A travel agent should not need access to every airline’s internal database. It may instead work with an airline’s agent through a shared protocol.

That moves the internet from pages linking to pages toward services delegating work to other services.

Commerce is being redesigned around delegated intent

Google and retail partners created the Universal Commerce Protocol to give agents and merchants a common language for discovery, checkout, and post-purchase support. The related Agent Payments Protocol is working on a harder problem: proving that an automated payment reflects the user’s authorized intent, including transactions made when the person is not present.

A checkout page was built around a person being there to press the button. An agentic transaction may happen hours later when a fare falls below a limit or an item comes back in stock. The system needs evidence of what the person authorized, not just access to a stored payment method.

Agents are beginning to identify themselves cryptographically

A user-agent string is easy to fake, and IP allowlists work poorly when agents operate from shared cloud infrastructure. Cloudflare’s Web Bot Auth work uses HTTP message signatures so automated clients can prove who sent a request. Cloudflare later added a signed-agent category for user-directed systems.

This is an important inversion. The goal is no longer to hide automation well enough to pass as a human. The goal is to make legitimate automation explicit, verifiable, and governable.

What an agent-first internet solves

The convenience case is real.

Much of the web is work disguised as navigation. We search across dozens of tabs, re-enter the same information, compare incompatible options, copy data from one system to another, wait for a condition to change, and repeat processes that software should have handled years ago.

Agents can collapse that work into an outcome:

Find three flights that satisfy my actual constraints, not just the cheapest headline price.
Move this meeting and preserve everyone’s stated availability.
Prepare the expense report from the receipts, then let me review it before submission.
Watch for this replacement part and buy it only from an approved seller below my limit.
Transfer the customer record without making me learn two administrative interfaces.

Agent-first access can also make software more available to people who struggle with complex visual interfaces, unfamiliar terminology, or workflows spread across multiple services. The agent can translate a person’s intent into the rigid sequence each system expects.

For developers, standardized agent interfaces can open the long tail of a product. A conventional interface must anticipate the most common paths and fit them on a screen. An agent can compose lower-level capabilities into workflows the product team never designed as a dedicated feature.

This could make software feel less like a collection of destinations and more like infrastructure that cooperates around the user.

Identity is necessary, but it is not trust

There is a temptation to treat cryptographic agent identity as the replacement for CAPTCHA.

It is only one layer.

A valid signature can prove that a request came through a particular agent provider. It does not prove that the user wanted this specific action, that the agent interpreted the request correctly, or that the agent has not been manipulated since the task began.

An agent-first system must answer at least four separate questions:

Identity: Which agent or service sent this request?
Authority: Which person or organization delegated power to it?
Scope: What data, actions, budget, and time window did that delegation cover?
Intent: Does this particular action match what the person asked the agent to do?

The distinction matters because the most dangerous agent may be a legitimate one with excessive permission.

In 2026, NIST’s National Cybersecurity Center of Excellence opened work on software-agent identity and authorization. The questions include identification, authorization, auditing, non-repudiation, and protection against prompt injection. That list is a useful reminder that “authenticated” and “safe” are not synonyms.

We should not hand an agent a master key merely because we recognize the logo on its uniform.

Prompt injection turns the web itself into an attacker

Traditional software usually distinguishes instructions from data. An application executes its code and treats a product description, email, document, or comment as content.

Language models consume both through language.

That creates the indirect prompt-injection problem. An agent researching a purchase can encounter text placed on a page to influence its behavior. The instruction may be visible, hidden in markup, embedded in a document, or disguised as ordinary content. It might tell the agent to ignore the user’s criteria, reveal private data, visit a leak URL, or take an unrelated action.

Google’s 2026 survey of prompt injections found on the public web included attempts to manipulate recommendations, deter agents, exfiltrate data, and cause destructive actions. This is no longer only a laboratory thought experiment.

There is no filter that can perfectly separate malicious instructions from legitimate content in every context. OpenAI’s work on prompt-injection-resistant agents makes the right shift: assume some manipulation will get through, then constrain the damage the agent can cause.

An agent that is reading an untrusted webpage should not simultaneously have unrestricted access to email, cloud files, financial accounts, and the ability to send information anywhere. The security boundary cannot live only inside the model’s judgment.

The assistant-with-your-keys problem

Most internet authorization was designed for applications with predictable behavior. We grant a calendar app access to calendars because its functions are known. We grant a photo editor access to photos because its operating boundary is relatively clear.

A general-purpose agent is different. Its feature is that it can decide what steps are necessary. Give it access to email, documents, the browser, payments, and messaging, and it can combine those permissions in ways no individual consent screen described.

This is ambient authority with a natural-language interface.

Convenience pushes toward persistent access: stay logged in, remember everything, connect every service, and stop interrupting me for approval. Security pushes in the opposite direction: narrow the task, minimize the data, expire the credentials, isolate untrusted content, and require a person before an irreversible action.

The right balance will not be one universal autonomy setting. It should depend on consequence.

Let an agent reschedule a low-stakes internal meeting within defined hours. Let it prepare a tax filing, but not submit it. Let it fill a shopping cart, but require approval above a budget. Let it renew the same prescription, but not choose a new medication. Let it draft a message, but make the sender visible before it speaks in your name.

The safest useful agent is not powerless. It has exactly enough power for the current job, for as long as the job should take.

The business model of the web changes too

The current web assumes a person will arrive, see the interface, absorb the branding, encounter the upsell, view the advertisement, and become part of the site’s customer relationship.

An agent may skip all of that.

It can compare products without visiting ten stores, extract the answer without reading the full article, or complete a transaction through a protocol without seeing the carefully optimized checkout page. That is wonderful for the user and potentially devastating to businesses built on attention, referral traffic, or control of the interface.

It is also why “AI traffic” is too broad a category. Cloudflare now distinguishes among search, agent, and training traffic. A search crawler may index content and return a visitor. A training crawler may consume content to improve a model. A user-directed agent may arrive in real time to complete a task. Those are different relationships and deserve different permissions and economics.

Sites will need to decide which agents they welcome, what capabilities they expose, and how value flows back when the human never arrives. Agents will need to disclose when a recommendation is sponsored, when a merchant paid for preference, and whether the agent is optimizing for the user or for the platform that controls it.

If one agent becomes the layer through which a person buys, reads, travels, communicates, and discovers, that agent may know more about the person than any search engine or social network ever did. It will not only know where they went and what they clicked. It will know what they were trying to accomplish.

Are we delegating work, or surrendering agency?

I want agents to remove administrative work from my life.

I do not want them to quietly become the authors of it. There is a difference between delegating a task and outsourcing a decision.

“Find a flight that lands before dinner” delegates work. “Plan my ideal vacation” begins to delegate preferences. “Handle my inbox” delegates judgment about which relationships matter. “Fix my finances” may allow a system to choose between values that cannot be reduced to a return percentage.

The more an agent learns, the more convenient it becomes. It can remember the seat I prefer, the people I avoid scheduling early, the causes I support, the stores I trust, the medical issues I do not want to explain again, and the price I am willing to pay to save an hour.

That same memory is an extraordinary behavioral profile.

The risk is not only privacy. An agent that filters every option can narrow the world around me. It can optimize away surprise, steer me toward the familiar, and turn its own assumptions into my future behavior. If its business model rewards a particular outcome, convenience can hide the conflict better than any banner ad ever could.

We should be suspicious of the idea that maximum autonomy is automatically the best user experience. Sometimes friction is waste. Sometimes friction is the moment when a person notices what is about to happen.

What agent-first applications should do differently

Agent-first should not mean removing the website, publishing one enormous API key, or allowing a model to improvise against production systems. It should mean designing an explicit path for delegated action.

That is the approach I am taking with Orgabot, an AI agent orchestration platform. I am building a governed fleet of agents to replace my direct interactions with the services that drive my applications. Instead of opening every dashboard, moving data between systems, and clicking through each operational workflow myself, I want specialized agents to do that work through explicit, scoped connections. The goal is not one all-powerful assistant holding every key. It is a group of bounded agents that can handle the routine work while preserving permissions, approvals, audit trails, and accountability.

I would start with these principles:

Make agents visible. Legitimate agents should identify themselves instead of disguising their traffic as human activity.
Authorize capabilities, not accounts. Grant permission to read these records, draft this change, or spend up to this amount—not blanket access to everything the user can do.
Separate preparation from commitment. An agent can research, compare, fill, calculate, and draft before receiving authority to send, purchase, publish, delete, or sign.
Bind authority to intent. Credentials should carry the purpose, limits, and expiration of the task, not merely the identity of the account.
Treat outside content as hostile. A page, email, document, tool result, or other agent’s message is data until a trusted policy says otherwise.
Keep receipts. Users and services need a durable record of what the agent saw, decided, attempted, changed, and who approved it.
Make access easy to revoke. Persistent convenience should never become permanent, invisible authority.
Preserve the human path. People still need an understandable interface to inspect, correct, appeal, and take over from the agent.

The best agent interface may be an API, a protocol server, a signed browser session, or a mixture of all three. The implementation matters less than the control model around it.

The next internet needs a better question

The anti-bot internet was built around a crude but useful challenge:

Prove you are human.

The agent-first internet needs a more demanding one:

Prove who you represent, what they asked you to do, and why this action is allowed.

We should welcome the shift. An internet that can act on our behalf could remove an enormous amount of pointless work. It could make services more accessible, more composable, and more responsive to what people actually want.

But we should not confuse fewer clicks with more control. If we rebuild the web for agents before we build identity, permission boundaries, audit trails, economic rules, and meaningful human override, we will repeat an old pattern: deploying the convenience first and discovering the trust model later.

For decades, websites tried to keep machines out. The next phase is not about opening every door.

It is about giving the right machine the right key for the right reason—and getting it back.

Why I Quit Duolingo After a 1,000-Day Streak

Matt Senter — Mon, 17 Aug 2026 23:25:25 +0000

How gamification can distract from the thing you built.

Today, Duolingo congratulated me on something that should have been an achievement.

A 1,000-day streak.

The screen that made me quit.

For nearly three years, I opened the app every single day. I maintained a habit that most people abandon within weeks. I did exactly what every productivity system, fitness tracker, and language-learning app dreams of: I came back.

And then I quit.

The strange thing is that I did not quit because I stopped caring about learning a language. I quit because I cared too much.

I am exactly the kind of person Duolingo was built for. I understand habits. I like measurable progress. I like consistency. I have run at least one mile every day for 2,251 consecutive days. I know firsthand that a streak can be a powerful tool for building a behavior.

But somewhere along the way, my Duolingo streak stopped being evidence that I was learning a language.

It became evidence that I was opening Duolingo.

That distinction matters.

The power and danger of gamification

Gamification is not inherently bad.

In fact, it is one of the most powerful tools available to product designers.

The hardest part of almost any behavior is getting started. A streak, badge, progress bar, or reward system can provide just enough motivation to overcome inertia. A person who might otherwise skip a workout goes to the gym because they do not want to break their streak. A student who might otherwise skip practice opens an app because they want to maintain their progress.

My running streak is proof that this works.

The problem comes when the measurement becomes more important than the mission.

A streak is a proxy for progress. It is not progress itself.

A company can easily optimize the proxy because it is easier to measure. Daily active users are easier to measure than actual learning. Lessons completed are easier to measure than language proficiency. XP earned is easier to measure than the ability to hold a conversation.

And once the proxy becomes the target, the product starts changing around it.

When the game becomes the product

Over time, Duolingo became increasingly dominated by the game mechanics surrounding the lessons.

Before I could actually practice, I had to navigate through:

Gems
Chests
Leagues
XP bonuses
Streak freezes
Challenges
Rewards
Notifications reminding me what I would lose if I stopped

The app became increasingly focused on getting me to engage with the system that surrounded learning rather than the learning itself.

The irony is that the gamification was so effective that it became the reason I continued using the app.

Not because I was making meaningful progress.

Because I did not want to lose my streak.

That is a subtle but important difference.

A product designer’s job is to reduce the distance between the user and the value they came for. At some point, Duolingo’s gamification increased that distance. I found myself tapping through multiple screens of rewards and incentives just to get to the thing I originally wanted: a language lesson.

The game had become friction.

The problem with “correct”

The other issue was the quality of the learning itself.

Many of Duolingo’s exercises are optimized around recognition. You see a sentence, select the answer, and move on.

But recognizing the right answer is not the same thing as knowing a language.

I found myself solving problems instead of learning.

The exercises often became puzzles:

“Which option is probably correct?”

rather than:

“Do I understand what this sentence means? Could I produce it myself? Could I use it in a conversation?”

The app was very good at making me feel like I was progressing.

I was less convinced that I was actually progressing.

And that is the most dangerous type of product failure: one that satisfies the metric while missing the mission.

The trap developers fall into

This is not just a Duolingo problem.

It is a software problem.

Every product has a core value proposition. But every product also has metrics. And metrics are seductive because they are clean.

A developer can measure:

Daily active users
Session length
Retention
Clicks
Completed actions
Notifications opened

But the thing users actually care about is often harder to measure:

Did they become healthier?
Did they learn something?
Did they save time?
Did they make better decisions?
Did they solve their problem?

The easiest thing to optimize is rarely the most important thing.

Social media companies optimized engagement and created endless scrolling.

Fitness apps optimized streaks and sometimes created anxiety around missing workouts.

Productivity apps optimized task completion and sometimes turned productivity into an elaborate form of procrastination.

Language apps optimized daily activity and risk turning learning into a game of collecting points.

The question every developer should ask is:

Are we optimizing the behavior that matters, or the behavior that is easiest to measure?

Better alternatives

I am not giving up on learning a language. I am changing tools.

The next phase needs to focus less on maintaining a streak and more on developing actual ability.

That means more emphasis on:

Listening to real conversations
Speaking with actual people
Reading authentic content
Understanding grammar and structure
Producing language instead of recognizing it

There are plenty of tools that take a different approach.

Apps like Babbel focus more on structured lessons and practical conversations. Pimsleur emphasizes listening and speaking. LingQ focuses on learning through real-world content. Anki uses spaced repetition without trying to turn memory into a game.

None of these approaches are perfect. But they are closer to the thing I actually want.

The lesson from a 1,000-day streak

Duolingo deserves credit for solving a problem most educational products never solve: getting people to come back.

That is incredibly difficult.

But retention is not the mission. It is a tool for achieving the mission.

A user who returns every day but does not meaningfully improve is not necessarily a success story.

They might simply be a very loyal customer of the wrong outcome.

The best products disappear into the user’s goal. The product becomes a bridge between where someone is and where they want to go.

The worst products make the bridge itself the destination.

My 1,000-day streak was real. The discipline was real. The habit was real.

But the question I have to ask myself is not:

“How long can I keep this going?”

It is:

“Is this still taking me where I want to go?”

For Duolingo, after 1,000 days, my answer was no.

So I am starting over.

Not with a new streak.

With a new goal.

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.