Skip to main content
Wildo.ai Coming soon
← All posts

Building serious software

Writing code is easier. Building serious software is not.

Good code is not a full product. AI robots hold working code amid tangled enterprise systems; Wildo connects those systems into an organized application factory.

I’ll say it plainly: AI agents write better code than I do. By quite a margin.

And increasingly, I find the same thing with code architecture. They know technologies I have barely touched, remember details I would have to look up, and suggest solutions I would not have found on my own.

Honestly? I think that’s fantastic. I’m building with capabilities I could never have had working alone a few years ago.

Good code is not a full product. Building a B2B application asks much more of you.

Your customer brings an entire company with them

You might have a brilliant idea and an interface people love. Then a prospective customer asks whether they can connect their identity provider. Their security team wants your audit events in its monitoring system. Someone needs finer access controls. Someone else needs to know how data is retained and deleted.

The conversation gets crowded quickly: SSO, OIDC, SAML, SCIM, passkeys, MFA, authorization, tenant isolation, audit trails, SIEM integration. APIs, webhooks, MCP and A2A. Localization, theming, accessible interfaces. Monitoring, deployment, backups and recovery.

Then come the security and assurance questions: OWASP, NIST, SOC 2, GDPR. Different kinds of requirements, different kinds of evidence, and considerably more work than adding another dependency.

Not every customer needs every item. But the one they do need can decide whether they are able to buy your product at all.

Meanwhile, the competition hasn’t paused. Your product still needs thoughtful design, a good frontend, reliable infrastructure and a reason to exist among all the other options. Meeting the entry requirements doesn’t automatically make it desirable.

“Make all of that work together. Don’t make mistakes.”

I have tried giving an AI some version of that instruction.

It did not work. ;)

The difficult part is the space between the features. An identity has to mean the same thing across sign-in, organization membership and access decisions. An action exposed to an agent needs to respect the application’s permissions. An audit event needs enough context to explain what happened. A change in one place can disturb an assumption somewhere else.

You can have individually convincing implementations and still end up with an application that doesn’t hold together.

Working through that takes attention. Start with the big picture, break it into concrete behavior, then keep going down into the details. Follow the same rule through every place that consumes it. Exercise the ordinary paths, the refusals and the awkward combinations. Go back when the result reveals something you missed.

AI helps enormously with that work too. But a broad instruction doesn’t replace the work. Someone has to keep the whole product in view while the details are being built and tested.

Two AI robots hold checked code while struggling with tangled connections between identity, security, integrations, compliance and operations.
The code can be right while the product still does not hold together.

And you still haven’t built the reason people want it

This is the part that bothers me most.

You can spend months doing necessary engineering and barely touch the original idea. The workflow you understood differently. The interaction that makes a difficult job feel simple. The small choices that give the product its character.

I’ve seen companies lose themselves in both directions.

Some become very good at satisfying requirements. They accumulate integrations, settings and assurances, while the product gradually loses the thing that made it interesting.

Others create something wonderful to use, but a company cannot adopt it. It doesn’t fit their systems, their security expectations or their obligations. People love the demonstration, and the purchase goes nowhere.

Neither outcome is what the team set out to build. You need the substance that makes the application acceptable and the taste that makes it worth choosing.

That’s why I created Wildo

I wanted the recurring foundations of a professional application to be something we could build on together, with their connections already considered.

A product designer and an AI robot shape an application together while the Wildo factory connects the shared mechanisms behind them.
Wildo provides the shared machinery. You and your agents shape the product.

Wildo combines an application engine with the knowledge and tools coding agents need to work with it. Identity, permissions, data, files, audit, integrations and other shared capabilities belong to that foundation. The work includes how they interact, how an application configures them and how its own code extends them.

That gives your project a different starting point. Your agents can spend more of their effort on the business behavior and experience that make your application yours, using shared mechanisms for the groundwork around it.

There are still decisions to make, behavior to verify and responsibilities that belong to the team running the product. Those deserve attention. They shouldn’t consume all the attention you had for the idea itself.

That’s what I’m trying to make possible with Wildo: use the extraordinary coding ability AI gives us, meet the demands of real business software, and keep enough room to build something with a point of view.