What happens when you can build it all yourself

I got the most complicated backend I have ever built to alpha in less than two weeks. The worrying part is how quickly that started to feel like a reasonable expectation.

Over the past few weeks I have shipped a new Noord site, expanded and released a design system, built a workspace for people and AI agents, and launched three workbooks. I am pleased with the work. I am also watching my definition of a normal amount of work become completely unreasonable.

Nobody has imposed this on me. That would at least give me someone to complain about.

Speed

The Noord site rebuild ran from late August into early September. Vlak had its first release on 4 September, followed by the main announcement on the 8th. Bureau's first prototype shipped 10 September; by the 18th it had an invitation-based alpha and a waitlist. I publicly launched The New Standard on the 22nd. On the 25th, the approval email arrived for Vlak's ChatGPT plugin.

The workbooks have been in the works for years. They bring together my research, writing and thinking about leveling, compensation and development: what responsibility means, how people get paid, and what actually helps someone grow.

AI helped me turn that work into something considerably more useful than a PDF. Stripe checkout, paid access, interactive tools, editable templates: parts of the project that could each have become a separate undertaking came together quickly. I could also integrate recent, sourced salary and compensation references into the guide, with dates and explanations of what the numbers do and do not mean. These need updating as the market changes. It also leaves time for me to explore a print run of the workbooks.

Some of the speed, then, is old work finally getting out of the house. Divide years of thinking by the days spent building the checkout and you get an excellent productivity statistic. You also get nonsense.

Building the things I needed to build the things

At Noord, I build products and interfaces with the help of our own agents. I need to find out whether an interaction works, whether the product is useful, and whether it deserves more investment. A convincing-looking screen can make all three questions harder to answer.

I know this because I like making convincing-looking screens.

Vlak is a deliberately quiet design language for that work. Consistent components and restrained styling let us compare interactions without redesigning the visual world around each one.

I still care about how it looks. I want the design to help us notice a weak idea before we have fallen in love with the ease of its transitions or adherence to a particular platform.

Through September it grew into more than 200 components, documentation, videos and 30 downloadable interface starters.

The next problem was bringing the work I was doing with different agents into one place.

I also wanted my human collaborators in there. I’m building with Fable/Opus, Astra and Grok at the same time, and I wanted one interface where I could talk to all three. Otherwise I’m copying things between chats, explaining what another agent did, and bringing people up to speed on work they couldn’t see happen.

So I built Bureau: Slack-style channels, with agents attached to the workspace rather than one person's private conversation. People can work with the same agents and see the work together. I wanted agents to participate in the team, instead of making each person the courier between their AI and everyone else.

Not living (physically) in the Bay Area anymore helps see the disconnect between frontier work and the rest of the world.

Watching someone work with an agent in real time is much more instructive. You see what they give it, where it gets stuck, and how they correct it. Those exchanges are useful to everyone else in the channel, including the person who has barely used an agent yet. I want people to be able to learn by watching each other work.

Building Bureau was the biggest technical departure for me. My building had mostly been on the front end. Bureau needed a real backend: accounts, workspace boundaries, shared conversations, permissions and agent jobs that keep running after someone closes the app. It is the most sophisticated backend I have built, on a stack I had not worked with before.

I've built an explanation into the end of every run. The agent has to walk me through what it built and how it works. I need that especially on the backend, where I have less experience. I want to understand the code I’m now responsible for.

At the moment, I’d put my time at roughly 40% new features, 40% agent and infrastructure architecture, and 20% interface polish. That is a very different working day from the frontend projects I used to focus on.

The bar keeps moving

The immediate effect has not been that I ship things faster or better than my teams could.

I just include more. The book gets an interactive tool. The design system gets installable starters, documentation and a plugin. The prototype becomes a shared workspace. The point at which I would once have been delighted to stop becomes the point at which I notice what is missing.

Some of that is a genuine improvement in quality. A reader who can test a pay decision gets more than a reader who can only read about one. Some of it is me expanding the job because the next piece is suddenly possible. From inside the work, those can feel remarkably similar.

The skill gaps are becoming clearer too. I can build a lot, but making Bureau more efficient means getting into server hooks, tracing slow responses and working through the code until the interface feels quick. That means spending a few evenings really pushing on React Virtual (thanks, Koen). I find that work deeply valuable and incessantly boring. This is inconvenient, because the app still needs it.

That puts a direct limit on how good Bureau can become if I’m the only person running it. I can ask an agent to help, but I still have to judge the result and keep paying attention. There are people with both the experience and the appetite to take that work much further. Building more is making it easier to see where I need them.

Shipping is also becoming suspiciously rewarding. You make a decision, something changes, you can use it, and then you can do it again. The gap between wanting a thing and seeing it exist is short enough to keep pulling me back in.

What concerns me is how quickly I adapt. Something that would recently have felt like a major undertaking becomes the minimum I expect from myself. I want the higher bar. I am less sure I want every available hour to become evidence that I could have shipped one more thing.

What should become a company?

Vlak helps us build, the workbooks package years of thinking, and Bureau is a bet on how teams could work together. They have different reasons to exist. But the question that interests me is much wider than my own projects: what happens across software when far more people can make what they need?

I expect more useful software to live outside startups. Someone makes a tool for their own work, a team adapts it, a small business sells it to paying customers. None of these has to become a venture-backed company. A useful product does not owe anyone a funding announcement.

That changes the competition a founder has to think about. The alternative to a new product might be another startup, something the customer can build in-house, or a feature their existing supplier could add. A founder still needs to explain why someone would choose their product and keep choosing it after the alternatives improve.

A working demo can show which problem a founder noticed and what they chose to leave out. As more people can produce one, I expect it to carry less weight on its own in a funding decision. It cannot show that customers will change how they work, keep using the product, or pay someone else to run it.

My view is that, unless a software startup is doing frontier work, the majority of the money it raises should go toward discovering or building distribution channels. If the science or technical feasibility is genuinely unresolved, funding the build is the bet. But if you are building on capabilities that already exist, I would want a much better explanation for why most of the round needs to disappear into product development.

Distribution might mean a partner whose customers need what you make, a community where you earn people's trust, or an integration that puts the product inside work they already do. It might be built into the product, with one person bringing their colleagues in because it becomes useful together.

Early money should buy enough experiments to discover which of those routes brings people who actually use the product and stay. Then it can pay to make a working channel repeatable and reach more of them. Buying traffic before you know that is an expensive way to get a chart.

This is about what the spending achieves, not which department receives it. An integration that gives a company access to an existing customer base can be distribution work. An integration that merely adds another feature still needs a different justification. Product quality, security and reliability need funding too. But another quarter of features should not be the default answer to why the company needs another quarter of runway.

I would want a funding pitch to spend less time proving that the founder can build, and more time showing why customers will make room for what they built.

I am enjoying this enormously. I like that a book can contain a working tool, and that wanting a different way to collaborate can lead to building one.

I want to keep this ability. I also want to be able to leave an idea alone without feeling that I have wasted the afternoon.

© 2026 Renato Valdés-Olmos