Joshua O • Dec 23, 2025 • 4 min read • 647 words
Most problems are solved.
Breathe in, let it out. Users don't need another shiny solution that can dance on one foot while balancing plates and querying Anthropic's API. They need technology that flexes to how they work, without enrolling in a course to learn how to babysit your software.
The value has shifted from "can it do X" to "can it do X my way." Every user is a problem to solve. So how do you build when locking your product to a specific workflow isolates the moving majority?
You're going to say AI. You probably already did, didn't you?
Naturally, everyone's doing it. Putting AI on something makes you cutting edge. But what happens when the landscape shifts again?
First we had copy-paste from chat to codebase. Then OpenAI made custom GPTs and products jumped to that, but it was too locked in. So people started guessing. Is it connectors? Do we use their APIs to build custom agents? Rely on the exploding AI startups that each solve one specific issue from the countless your company faces daily? How about we just feed all our data to an LLM and have it do the thing, that’ll work, right?
Then MCP arrived. Now everyone's adding MCP to everything, patching where it falls short, creating further disparity in their infras. Until they update the spec and you're scrambling to match it. Oh wait, there's this new RAG approach with Skills that'll surely do the trick. Let me try to convince my colleagues who just bought into the previous Tools architecture.
It's cool because we can always be busy 💰. But wouldn't it be better to get busy on actually exciting problems instead of chasing the interface?
Here's the crazy part: Products are configuration moonlighting as architecture.
Take PostHog, where I work. Analytics, error tracking, session replay: same skeleton (capture → schema → query → visualize), different parameters. Look at what users are actually doing:
Take one of the top issues: Feature flags based on events (or behavioral cohorts)
30+ users directly asking for "event-based targeting." But the actual ask is behavioral targeting, and the primitives already support it: person properties, timestamps, flag schedules. The architecture is there. The product just hasn't exposed it yet.
Here's the workaround: $set a person property with a timestamp when the event fires, target your flag to that property. Want "user did X in the last 30 days"? Combine with flag schedules. It already works. The product just makes you assemble it yourself.
I merged a step toward making this easier: recurring schedules so the temporal targeting resets automatically. Small surface change with the same underlying primitives.
And once again, you might reach for AI. But "what should we do with AI?" is the wrong question. Solution hunting for problems. If you don't have a problem AI solves, you don't need AI. Odds are you're underutilizing it for problems it already handles well, because your system isn't optimized for it.
Don’t solve your product, solve your infra. Your system needs to be consumable from any interface, current or future, without adjusting fundamentals for each new one.
I'm building toward this: an architecture where AI becomes just another consumer of your system's truth, not a special case requiring its own plumbing. But the pattern matters more than my implementation.
So here's the challenge: How would you build a core that anything can learn from (forms, integrations, agents) without AI being architecturally special?
Hint: Isn't that what APIs were always meant to be?