The premise
Most ideas don't get built. A small minority that do, take far longer and cost far more than they should, because the cost of turning an idea into working software has always required a specific, scarce, expensive professional class — software engineers — to translate intent into syntax.
That bottleneck has been the unspoken governor on what software exists. The world's catalogue of working software is not a representation of what was useful to build; it's a representation of what was important enough to justify a professional to build it. Whole classes of software — internal tools that would save a small team's afternoon, the tenth landing variant for a campaign that gets two thousand visits, the bespoke micro-app for one client — never crossed the threshold.
What changed
By 2024, large language models could produce competent code from natural-language descriptions. By 2025, they could produce competent designs and connect to real backends. By 2026, the gap between "describe what you want" and "the thing exists, hosted, working" had collapsed from months to minutes for the 80% of software that's mostly plumbing.
That 80% is a much larger surface than it sounds. It includes the SaaS your business needs, most internal tools, every marketing site, the per-customer demo, the experiment you keep meaning to run. It does not include all software — there's a real 20% that needs deep technical judgement, custom infra, or the kind of architectural decisions that only humans make well — but the 80% is enough to remake who gets to build.
The shift
When the cost of building software drops by an order of magnitude, the question that decides what gets built changes. It used to be "is this important enough to justify an engineer's time?" That filter selected for size, for revenue potential, for political clout inside a company. Many useful things failed it.
The new question is "is this useful enough to spend an hour describing?" That filter is far more permissive, and it selects on different axes — usefulness to a specific person, fit to a specific moment, willingness to iterate quickly. Software starts looking less like a fixed asset and more like a piece of correspondence: written for a purpose, used, sometimes kept, often replaced.
What Marcus is for
Marcus is the tool for the people who'd write that correspondence. A founder who'd build the first version of their company in a week instead of paying €220K for a year of engineering. A product manager who'd hand the team a working URL instead of a 12-page PRD. An ops manager who'd ship the refund console themselves rather than wait three quarters for engineering's roadmap to bend. A designer whose Figma frame goes live as a hosted, accessible, production-grade page the same afternoon.
None of these people are trying to put software engineers out of work. They're trying to do their own jobs better, in environments where the engineering team can't afford to spend cycles on the long tail of small, important software. Marcus closes that gap.
What we won't do
We will not train models on your data. The whole point of this medium is that what you build is yours. If a future Marcus feature ever calls for opt-in training data, it will be opt-in, individually consented, clearly compensated.
We will not optimise for engagement. Marcus is a tool. The fewer minutes you spend in our UI before having something real to show, the better we've done. We measure ourselves on time-to-first-shipped-page, not weekly active users.
We will not gate basic features behind seat-tax pricing. The economics of generation are per-project, not per-person, so our pricing is too. A team of fifty pays the same as a team of three for the same project.
The longer arc
If we're right about what's changing, the next decade has more software, made by a wider set of people, used for shorter spans, and replaced more often. The institutional advantage shifts from "we have engineering capacity" to "we have judgement about what to build". Companies that compound that judgement — small teams that ship many small experiments and learn from each — outpace companies that still rely on long planning cycles and large engineering investments.
That's the outcome Marcus is built to enable. Not "everyone is a programmer now" — most people don't want to be, and shouldn't have to be. But "everyone who knows what should exist can make it exist". That's the change worth working on.
Where we are
Early. Marcus is a small team, shipping every week, with paying customers in early access. We have opinions about what good looks like and we encode them in the system. We're building the first version of a product that we expect to look very different in three years — but that gets paying customers shipped before this Friday.
If you want to build with us, start a project. If you want to build for us, we're hiring. If you want to argue with us, join the room. The point of writing this down is so the people who read past the first paragraph self-select.