Two years ago I was running operations at a B2B software company. My business partner was running it with me, and he'd been building it for a long time before I came on. It's a good company. The software is genuinely impressive. The customers are enterprise, the sales cycles are long, the implementations are longer, and every deal feels like you're being graded by a committee of people who've been doing this since before I could drive.
That's not a complaint. B2B is hard in a specific way, and doing it well teaches you things about patience and discipline that most of software ignores. But somewhere between the fifth AI-adjacent product demo we watched and the twentieth time I heard someone say "the tooling has fundamentally changed," we decided we wanted to go build things at a faster cadence.
So we did. We started a for-profit corporation called Infinite Orchard. Two founders, no investors, no board of outsiders, no roadmap promised to anyone but ourselves. We stood the company up the correct way, which took longer than the fun parts of building ever do, and then we went back to work.
The plan is a portfolio. Not one flagship app. A lot of small ones, some medium ones, and larger ones beyond. The thesis is simple: the cost of building good software has come down enough that a small team can cover surface area that used to require a much bigger one. The economics of running many modest products, done well, will beat the economics of betting everything on one.
How we decide what to build
Every candidate on our list gets a complexity score before we start. The score is what shapes the build, not a fixed playbook. Low-complexity ideas ship quickly as browser-only tools and live inside a shared portfolio site. Higher-complexity ideas get the room they need: accounts, data, payment, the full depth. The split isn't a pair of named tiers. It's a gradient, and the score picks where on the gradient each idea lands.
That lets us move at two very different cadences from the same team. Quick utilities keep us shipping every week. Heavier products get the time they need, which is usually longer than our initial guess.
What's actually different about doing this now
The honest answer is that the set of tools available to a small team in 2026 is genuinely better than it was three years ago. Not miraculously better. There's still a giant gap between what the demos promise and what the reality delivers. But enough better that two people can do things that would have been silly to attempt in 2022. We lean into that hard. We also treat a lot of the new tooling with the skepticism it deserves, because "it works in the demo" and "it works in production at 2 AM with a real user's data" are still very different claims.
What we're *not* doing is reinventing anything fundamental. We're not building new frameworks. We're not hand-rolling auth. We locked the stack early on React, Next.js, Tailwind, Convex, Keycloak, Cloudflare, Stripe, Resend, Axiom, and Sentry, and we refuse to let any single app deviate from it without a real reason. Every new product starts closer to shipping than the last one because the primitives are already resolved.
A lot of what we've actually built over the last year is less about any single app and more about the shared foundation that sits underneath them. Design systems. Deployment scripts. Testing conventions. Shared configuration. The kind of boring plumbing that means each new app starts further along than the last. That part is less glamorous than the apps themselves and it's the reason the apps exist at all.
Where we are, honestly
As of this writing:
- AppCrib is live and growing every week
- Paid acquisition is running on a few channels, tuned per toolkit
- Heavier products are working their way through the queue, none of them public yet
- Too many ideas, not enough built yet, which is probably the correct ratio
Plenty of things have gone wrong too. Most of them are the kind of small, grinding issues that eat a day and teach you nothing general. They don't show up in any pitch deck, and they aren't what we'd lead a post with.
What we're doing isn't novel. Every hacker newsletter from 2024 onward is full of people trying versions of this. What we think *is* a little novel is the discipline: treating this like a real company rather than a side project, locking the stack so we don't have to make the same decisions every week, and refusing to let the portfolio sprawl into incompatible shapes.
More to come. Next post: AppCrib. What it is, why we built it the way we did, and why the current utility-tool landscape makes us genuinely angry on behalf of developers.