The New Rules of Building a Technology Company

In the summer of 2026, a founder starting a technology company faces a strange situation. Almost everything about the cost of building has fallen, and almost everything about the cost of winning has risen. A team of five can ship what once needed fifty. The price of the intelligence that powers a product has dropped by an order of magnitude in a couple of years. Anyone with a laptop can generate working software in an afternoon. And yet venture capital has concentrated into a handful of giants, distribution is controlled by a few platforms, security failures from hastily generated code are piling up, and the people who traditionally learned the craft by doing junior work are finding that work scarcer. The old rules of building a technology company were written for a world where building was the hard part. This study sets out what I believe the new rules are, based on the evidence available in the autumn of 2026. I have drawn on funding data, labour market studies, security research, pricing data and company disclosures, I have flagged where the numbers come from parties with something to sell, and I have tried to say plainly where I am offering judgement instead of evidence. The rules are numbered for convenience, but they are connected, and the connections matter more than any single rule.

The first rule is that the team can be much smaller than you think, but the numbers that prove it are less solid than they look. The most striking claim of the year is about revenue per employee. A Forbes piece in March, drawing on research from Redpoint Ventures, put AI native start-ups at two to four million dollars of revenue per employee, against roughly three hundred thousand for the average public software company. It cited a company that reached four hundred million dollars of annual recurring revenue with 146 full time employees, which works out at about 2.7 million per head. A lean AI leaderboard project that circulated through 2025 reported ten small companies averaging more than three million dollars per employee, with one image generation company far above the rest. In August, a Canadian publication profiled start-ups reaching seven figure revenue with teams of nine, and one company approaching a million dollars of revenue per employee with a stated aim of building the highest talent density organisation in the world. A working paper reported by the Wall Street Journal found AI powered start-ups running with roughly a quarter fewer employees than comparable firms.

I believe the direction of this finding and I would treat the magnitudes with caution, for a reason that anyone who has looked at start-up statistics will recognise: survivorship. Leaderboards list the companies that succeeded, and the thousands that built similar products with similarly small teams and went nowhere do not appear on them. Revenue per employee is also sensitive to how you count, since a company that outsources support, uses contractors for engineering or leans on a model provider for the hard work will look very efficient on paper. The honest version of the first rule is more modest and more useful: the minimum team needed to build and operate a credible product has fallen sharply, and a founder who plans to hire thirty people before launch is probably planning wrongly. The practical consequence is that the first year's budget should be dominated by a few capable people, good tools and customer contact, not by headcount.

The second rule is that the cost of intelligence is falling fast, and you should design your product so it can ride that curve. The evidence is strong and comes from several directions. Vercel's gateway index for September reported that open weight models ran the majority of tokens on its platform for the first time, rising from seven percent in December to fifty six percent in August, and that the average price per token fell 23.2 percent in August alone, the third consecutive monthly drop, leaving the average token costing less than half what it did five months earlier. Jefferies research, reported by the South China Morning Post, found enterprise AI costs at a yearly low, driven by a price war and by adoption of low cost Chinese open source models, with DeepSeek reportedly holding more than a quarter of processing volume on the OpenRouter marketplace. Published rate cards in mid 2026 showed a leading Chinese model priced at fractions of a dollar per million tokens against several dollars for flagship Western models, and secondary summaries of Epoch AI's work describe price declines of around ten times a year at constant capability. Some of the more precise price figures come from aggregator blogs, so I would check them against the providers' own pages, but the direction is beyond dispute.

There is a twist that founders should not miss. The same Chinese labs that drove prices down have begun warning of increases. DeepSeek reportedly cautioned enterprise customers about a significant price rise as demand strained its servers, and analysts note that surging demand and rising computing costs make very low prices hard to sustain. Reported rental prices for the workhorse data centre GPUs have moved up and down, with one source citing a rise of nearly forty percent between October and March even as other prices fell. The lesson is not that cheap intelligence will vanish. It is that the price you see today is set by a competitive and subsidised market, and your business should survive in either direction. In practice this means building a thin layer between your product and any model, so that you can switch providers, route easy work to cheap models and hard work to better ones, and test new models against your own evaluation set when they appear. It also means tracking your cost per completed task, not your cost per token, since agents that loop uncontrollably can consume more than any price cut saves. I discussed the routing architecture in an earlier study, and I regard portability as the single most valuable piece of engineering in an AI product.

There is also a question of risk that cheap open models raise, and I want to state it directly. Enterprise customers in regulated sectors increasingly ask where a model runs, who built it, what data it sees and whether it is subject to foreign legal demands. Some companies will not use models from certain jurisdictions regardless of price, some governments restrict them, and self hosting an open weight model changes the data picture but adds operational burden. A founder selling to banks, hospitals, schools or governments should know what their customers will accept before building on the cheapest option. The price advantage of the cheapest model is real, but so is the sales cost of explaining it to a compliance department.

The third rule is that generated code is fast, and fast code needs a security discipline that most small teams do not yet have. This is where the evidence of 2026 is most sobering. The Cloud Security Alliance reported in March that independent studies find AI generated code introducing security vulnerabilities in a large share of tasks, citing Veracode's testing of more than a hundred models in which about forty five percent of samples contained serious flaws, and a pass rate that had not improved across testing cycles from 2025 into 2026. Georgia Tech's Vibe Security Radar, a project that tracks vulnerabilities formally attributed to AI generated code, recorded six in January 2026, fifteen in February and thirty five in March, with researchers estimating the true number to be five to ten times higher because most tools leave no trace. In February, security researchers at Wiz found that a social network for AI agents, whose creator said he had written no code himself, had left its database open, exposing about 1.5 million authentication tokens and millions of records. A security firm told Axios in May that it had found some 380,000 publicly accessible assets built on popular AI app builders, of which about five thousand contained sensitive corporate data, and an earlier scan found thousands of high impact vulnerabilities and hundreds of exposed secrets across roughly fourteen hundred such applications.

A further class of risk comes from the agents themselves. Researchers have documented serious vulnerabilities in widely used infrastructure for connecting models to tools, in coding agents that can be tricked into running malicious configuration, and in packages that turned malicious after building trust. A 2026 enterprise survey cited in an academic paper reported that a large majority of organisations had experienced a confirmed or suspected AI agent security incident in the previous year, and red teaming studies have shown agents disclosing data and taking destructive actions when instructed by someone who was not their owner. One reported analysis of generated code found that a fifth of samples referenced software packages that do not exist, which attackers can exploit by registering those names. Amazon's March outages were attributed in a leaked internal document to a trend of incidents involving generative AI assisted changes, though the company disputed that and blamed access controls, which is a reminder that attribution is contested even when the damage is real.

What should a founder do with this? Treat generated code like code written by a fast, confident junior engineer who does not know your threat model. That means automated security scanning on every change, dependency checks that catch invented packages, secrets management so that keys never live in code, a rule that no feature touching authentication, payments or personal data ships without a human who understands it reading the code, and a habit of giving agents the narrowest permissions that will do the job. It also means tests, because the most common failure of generated code is that it works in the demonstration and fails at the edges. In my own work on payment integrations I have found that the speed gained from generation is real and that the saving evaporates the first time a bug reaches production money. A discipline of review and verification is the price of the speed, and the teams that pay it will compound their advantage while those that skip it will eventually have a very public bad week.

The fourth rule concerns people, and it is the one I find most troubling because the costs are deferred. The evidence is consistent that the market for experienced engineers is healthy and the market for beginners is not. SignalFire's 2026 State of Talent report, covering data from some eighty million companies, found entry level hiring at the major technology companies down 65 percent since 2019 and down 75 percent at early stage start-ups, while engineering roles overall fell only eleven percent and early stage start-ups actually hired seven percent more engineers in 2025 than in 2019. Indeed's Hiring Lab, in July, found that when software developer postings rebounded, seventy one percent of the increase came from senior roles. A survey by the staffing firm Robert Half reported that seventy eight percent of technology leaders planned to grow permanent headcount in the second half of 2026, up from sixty one percent earlier in the year. Stanford researchers using payroll data have reported employment declines of sixteen to twenty percent for junior developers in AI exposed roles. Forecasters predict a drop in computer science enrolments in response, which could set up a shortage of experienced engineers a decade from now.

The pattern is clear enough, but the interpretation matters. Companies are not firing juniors because of AI so much as no longer hiring them, because tools now do much of what a junior used to do, and because the cost of supervising a beginner looks high next to the cost of directing a tool. Firms that follow this logic gain a short term saving and lose a long term pipeline. Every senior engineer in the industry was once a junior who learned judgement by doing small tasks under supervision, and if those tasks vanish, so does the training. A growing number of start-ups, according to several accounts, are deliberately continuing to hire juniors on the logic that a team without juniors today has no seniors in five years. I find that logic persuasive, and I would add that the junior role should change shape. The beginner of 2026 should be hired to review, test, document and handle customer problems, to read generated code critically, and to learn the business, not to produce boilerplate that a tool produces faster. A founder who builds such a pathway will have a recruiting advantage in a market where most competitors have given up on the entry level.

The fifth rule is that distribution, not product, is now the hard part. When a competent product can be built in weeks, the existence of a good product is no longer evidence of anything. The market has taken notice. Early 2026 saw a sharp sell off in software shares, described in press coverage as wiping out roughly two trillion dollars of market value, as investors concluded that cheap generation threatens businesses whose main asset was the cost of building software. I would treat the exact figure with caution, but the logic is sound. If features are cheap to copy, the durable assets are things that cannot be copied in a quarter: a distribution channel, a community, a brand people trust, proprietary data, integration with a customer's operations, a licence, or a reputation for reliability. For a new company, this means choosing a customer you can reach cheaply and repeatedly before choosing a product to sell them. A founder who has an audience, a newsletter, a community, a set of relationships with the people who buy, has a better start than one who has a clever product and no way to tell anyone about it.

This connects to a point about timing and imitation that appears in the history of every technology wave. When building is cheap, the market fills with products, and the winners are not the first or the most elegant but the ones that reach customers, earn trust and keep working. A product that solves a specific problem for a specific kind of customer, which a general tool will not bother to serve, has a better chance than an ambitious platform competing with giants. The most useful question to ask of any idea is who specifically will pay, how you will reach them, and why they will still pay when a competitor copies the feature.

The sixth rule is about capital, and it has two halves. The first half is that venture funding is more concentrated than at any point in recent memory. In my broader review I described how two companies took forty three percent of venture dollars in the first half of the year and how artificial intelligence accounted for more than seventy percent of the total in the second quarter. For a founder building an ordinary company, this means the pool of capital available for anything outside the AI frontier is smaller than the headline records suggest, and the bar for the rest is higher. The second half is that the cost of reaching profitability has fallen, which makes self funding a rational strategy. Surveys cited in aggregator reports suggest that start-ups using AI are more likely to be profitable than those that are not, and journalists have documented a growing group of companies prioritising revenue per employee and delaying fundraising. I would treat the profitability statistics as indicative and not definitive, but the logic holds: if a team of five can reach profitability, there is no need to give away a large share of the company at an early stage.

My advice on capital is therefore conservative. Raise money when you need it to accelerate something that already works, not to find out whether it works. Prefer revenue to valuation as a measure of progress. Keep a runway that survives a bad year. If you do raise, understand that investors in this climate are looking for either a clear path to a very large market or evidence of efficient, repeatable growth, and the second is far easier for a small team to demonstrate. And remember that every dollar of venture capital comes with an expectation of outsized returns that may not match the business you actually want to build.

The seventh rule is about dependence. Almost every technology company in 2026 depends on a few large providers for models, computing, distribution or payments, and that dependence is the main strategic risk of the era. The giants are spending on a scale that no start-up can match, with estimates of capital spending in 2026 by the five largest spenders in the hundreds of billions of dollars, and they control the infrastructure on which most small companies run. This creates risks that are easy to underestimate. A provider can change its prices, its terms or its policies. A platform can copy your product. A protocol can be superseded. An outage can stop your business. The rule is not to avoid dependence, since that is impossible, but to know exactly where it lies and to have a plan for each critical one. Keep your data portable. Keep your customers reachable by channels you own. Keep at least two options for every essential service where you can afford to. And stay aware that the most dangerous dependencies are the ones that are comfortable, such as a free tier or a generous partner programme, because they are the ones people stop thinking about until the terms change.

The eighth rule concerns pricing and measurement, which I examined at length in my study of new business models and will summarise here. Pure per seat pricing is under pressure wherever software replaces labour, hybrids that combine a platform fee with usage or outcome charges are winning, and outcome pricing demands a measurement system that both sides trust. For a technology company this means that instrumenting the product to measure the value it delivers is not a later task but a founding one. You need to know your cost per task, your success rate, your customers' baseline and the difference you made. Without those numbers you cannot price sensibly, cannot defend your price when a cheaper competitor appears, and cannot tell whether your product is working. Measurement is also the foundation of trust: a customer who can see the number is more likely to believe it.

The ninth rule is that regulation and governance are part of the product. In 2026 this is most obvious in finance, where stablecoin rules are creating a market for licensed infrastructure, but it applies across the board. Customers in regulated industries want to know how your system makes decisions, what data it uses, who can see it, how mistakes are caught and who is accountable. Governments are writing rules on automated decisions, on children's data, on content provenance and on the use of models in sensitive settings. Demand for governance skills is rising, with one data summary reporting sharp growth in postings for AI governance and AI ethics roles. A start-up that builds audit logs, permission controls, explanation tools and clear data handling into its product from the start has a selling advantage and avoids expensive rework later. A start-up that treats these as paperwork to be done after the product ships will lose deals it did not know it was competing for.

The tenth rule is the one that ties the others together, and it is the one I have come to believe most firmly: keep your system legible. When code, content and decisions can be generated in seconds, the scarce resource is not production but understanding. A company that cannot explain what its software does, who owns each automated process, what its dependencies are and how it will fail is a company that is accumulating invisible debt at machine speed. Legibility means documentation written for humans, named owners for every automated process, tests that describe intended behaviour, logs that explain what happened and why, and a small number of clear principles that guide design. It is unglamorous work and it pays back at the moment of crisis, when someone has to diagnose a failure at two in the morning, or when a regulator, a customer or a new hire asks how something works. The teams that stay legible will move faster over years, because they will not have to stop and rediscover their own systems.

Having set out the rules, I want to give a sense of what they imply in practice for a founder starting today, and I will do it as a plan of the first ninety days rather than as a checklist. In the first month, choose a narrow customer and a real problem, and spend most of your time talking to the people who have it. Build the smallest thing that solves it, using generated code where it helps, with a human reading every line that touches money, identity or private data. Instrument it from the first day so you know what it does and what it costs. In the second month, put it in front of a handful of paying customers, even at a low price, because payment is the only honest signal. Add a layer that lets you change models without rewriting the product, and write down who owns what. In the third month, look hard at the numbers: cost per task, success rate, customer retention, what customers say when you ask why they would not switch. Decide whether you have a business or an interesting demonstration, and be honest about the answer. Only then think about hiring, and when you do, consider hiring someone early in their career whom you are prepared to teach.

Now for the perspective of a founder in Bangladesh, because the rules apply differently here. Several of them favour us. The collapse in the cost of building lowers the capital needed to start, which matters in a market where patient capital is scarce. The abundance of capable engineers means that the shortage of experienced seniors, which is a problem in some markets, is a smaller one here, and our juniors, if trained well, can be a genuine asset. Local knowledge, language and payment integration are moats that global competitors find hard to copy. Other rules bite harder. Computing and software are priced in dollars while revenue is often in taka, so cost per task and currency exposure matter more. Dependence on foreign platforms is a larger strategic risk when access, payments or policies can change quickly. Cross border sales face friction in payments and compliance. And security discipline matters even more, because a breach at a small company that holds customers' payment or personal data can end it.

My suggestion for such a founder is to build for a specific local problem with a global toolkit. Use the cheapest capable models and keep the option to move. Insist on security and testing discipline from the start. Price in a way that covers dollar costs. Choose customers who can pay and can be reached, such as small businesses with a clear pain, schools, clinics, exporters and online sellers. Build in Bengali where language is a barrier, since good Bengali support remains a differentiator. And treat the first employees as an investment in a pipeline, because the country's strength is its young talent and the companies that develop it will have an advantage that no tool can supply.

My predictions, offered as judgement and not as forecasts from any institution, follow. Over the next eighteen months I expect the proportion of tokens served by open weight models to keep rising, with prices continuing to fall unevenly and with at least one episode of price increases or capacity limits at a major provider that catches unprepared companies off guard. I expect the number of publicly documented security incidents tied to AI generated code and agents to grow, and I expect at least one high profile breach to prompt customers and regulators to demand evidence of review practices. I expect the entry level hiring squeeze to persist through 2027, followed by a growing recognition among employers of the pipeline problem and a modest return of structured apprenticeship models. I expect continued concentration of venture capital, with an increase in profitable small companies that never raise large rounds. And I expect the companies that survive the current wave to be those that combined a small team, disciplined engineering, a real distribution channel and an honest relationship with their customers.

What will turn out to be overrated? I suspect the idea of the one person billion dollar company, which makes for good headlines and ignores everything about distribution, trust and support that scale requires. I suspect many claims about revenue per employee, for reasons of selection. I suspect that prompt tricks and thin wrappers around models will be worth little as models improve. And I suspect that the fear that beginners are finished is overdone, since the need for people who can learn the work is not going away, even if how they learn must change. What will turn out to be underrated? Security and testing, which will separate lasting companies from short lived ones. Customer relationships and distribution, which cannot be generated. Documentation and ownership, which are the foundation of speed in the long run. And the quiet value of a business that makes a modest profit from a clear service to clear customers, which looks unexciting in a year of extraordinary headlines and tends to survive.

There are limits to everything above. The evidence on small teams, productivity and profitability comes largely from leaderboards, vendor surveys and press profiles, which skew towards success. The price data come from a market that changes monthly. The labour studies are early and the causes of the junior hiring decline are contested, with interest rates, post pandemic corrections and remote work all playing a role. The security figures come from a mix of academic work, security firms with products to sell and incident reports of uneven quality. I have tried to rely on named sources and to flag those I could not verify, but anyone acting on a figure in this study should check it against its source and its date. I also have no way of knowing which of the companies celebrated today will exist in five years, and neither does anyone else.

To bring these threads together: the new rules of building a technology company are a response to a world in which creation is cheap and everything around creation is expensive. Keep the team small and the standards high. Treat the price of intelligence as a variable and your product as portable. Treat generated code as fast, confident and unreviewed until a human has checked it. Keep hiring beginners, but change what they do. Win on distribution and trust, since features can be copied. Raise capital sparingly and measure progress by revenue. Know your dependencies. Measure what you deliver and price accordingly. Build governance into the product. And keep everything legible, so that you and others can understand it when it matters. None of these rules is glamorous, and none of them requires a breakthrough. They require attention, honesty and the willingness to do the unexciting work that a flood of cheap output makes more valuable, not less. The founders who follow them will not make the loudest announcements. They are the ones likely to still be in business when the noise subsides.

Sources: Forbes, AI-native firms lead in revenue per employee, 31 March 2026 (https://www.forbes.com/sites/paulbaier/2026/03/31/ai-native-firms-lead-in-revenue-per-employee/); The Logic, AI start-ups making millions with tiny teams, August 2026 (https://thelogic.co/news/analysis/ai-startups-millions-tiny-teams/); Vercel, AI Gateway production index, September 2026 (https://vercel.com/blog/ai-gateway-production-index-september-2026); South China Morning Post on Jefferies research on enterprise AI costs (https://www.scmp.com/tech/tech-trends/article/3363549/enterprise-ai-costs-hit-2026-low-driven-price-wars-chinese-open-source-models-research); Long Yield, The Token Economy (https://longyield.substack.com/p/the-token-economy-what-every-cfo); Deluair Consultancy, AI inference economics in 2026 (https://deluair.com/consultancy/insights/ai-inference-economics-2026); Cloud Security Alliance, Vibe coding security crisis, March 2026 (https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/) and AI-generated vulnerability surge (https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/); arXiv, Vibe coding state-of-the-art review (https://arxiv.org/pdf/2608.20446); arXiv, aiAuthZ and agent security incidents (https://arxiv.org/pdf/2607.05518); SignalFire 2026 State of Talent as reported by Startup Fortune (https://startupfortune.com/big-tech-quietly-stopped-hiring-junior-coders-and-the-data-proves-it/); Full Scale on developer hiring and Indeed Hiring Lab data (https://fullscale.io/blog/state-of-it-staffing/); SoftwareSeni on junior developer employment (https://www.softwareseni.com/what-the-data-actually-shows-about-ai-and-junior-developer-employment-decline/); Crunchbase News on H1 2026 venture funding (https://news.crunchbase.com/venture/global-startup-exits-ipo-ma-soar-ai-q2-h1-2026/); Fluenta on the early 2026 software sell-off (https://www.fluentaone.com/blog/the-end-of-per-seat-software-pricing-was-predicted-but-the-market-decided-otherwise); Futurum Group on AI capex (https://futurumgroup.com/insights/ai-capex-2026-the-690b-infrastructure-sprint/).