Stop Rebuilding the Same Internal Tools

Engineering teams remain a bottleneck for internal tools despite AI making it cheap to create software, because owning production-grade software—with security, integrations, testing, and maintenance—still requires significant engineering effort. A marketer at an unnamed company built an interactive quiz with AI in days, but engineers still estimated six weeks to make it production-ready, highlighting the gap between vibe-coded prototypes and viable systems.

Stop Rebuilding the Same Internal Tools Agent-Native /blog/topics/agent-native Every engineering org has that one request that won't die. It gets deferred, it gets closed, it gets "revisited next quarter," and then it still somehow pops back up in Slack with a prayer hands emoji. For example, one of my marketer friends at another company wanted a short interactive quiz for a customer conference. Five questions, tell people which stage their company is in, give them some advice, and push the answers into the CRM so Sales could follow up. Engineering said okay, give us six weeks. As a dev, I get it. They weren't being jerks. The interactive quiz was important, sure, but it just happened to be less important than the ten other things already in flight, and the only people who could build the quiz were busy with those ten other things. So, my friend did what anyone does now. She went and built the quiz herself with AI. She got pretty far. The design wasn't too shabby, and the questions advanced, and the score calculated right. It looked almost shippable... minus the fact that it wasn't hooked up to production data or using any of the correct design system components. A lot of developers like me can see it clearly. And it's really hard to explain without sounding like I'm gatekeeping. Vibe-coded AI slop is convincing long before it's actually viable. When my marketer friend showed her engineers what she'd coded, they gave her the exact same estimate: six weeks. The work she did basically didn't matter. That didn't make sense to her. She could see the app working on her laptop. How hard could it really be? But to developers, we see a new production system: - scoring rules that someone will want to change mid-campaign - consent capture that legal will ask about - CRM writes with a credential that has to live somewhere real - attribution, so anyone can tell if it worked - accessibility, because the conference audience includes actual humans - analytics, error states, tests, deploys, monitoring - and an owner, six months after the conference banners come down Code has never been the hard part. The hard part is turning a one-off experience into something a company can safely depend on. And that's where we as engineers are, even with all the AI available to the rest of the team, still a bottleneck. Six weeks. Done properly. Secure, accessible, wired to the CRM, tested, observable. Genuinely good work. Then, the campaign starts. Marketing wants to reword question three. Then shift a scoring band. Then change the recommendation for one result. Each one is a ticket, because the domain logic is braided into an app only developers can safely touch. Next quarter, a different marketer needs a scored quiz for a different product. Different questions, scoring, copy, imagery. Plus one extra result type. Plus a different CRM object. Just enough variation that your app almost fits. So you either add conditionals until nobody can read the file, or you start another multi-week build. Fast forward a year and you own four almost-identical tools, each with its own forms, analytics, integrations, and special little collection of bugs. Not a great path either. So, both paths lead somewhere bad: Everything behind engineering? You become the company's all-too-human API. Synchronous, interrupt-driven, backed by a queue that never drains. Everyone builds independently? The queue comes back anyway, but messier, more urgent, and weirdly ownerless. Before AI, requests like this one often just… stayed manual. Internal software was too expensive to justify. Eventually, with enough refusals from eng, someone would just make a Google Form and move on. But AI raises everyone's expectations of what should be possible. Now it's cheap to create software. The problem is that it's still not cheap to own software. Those are wildly different costs and everybody keeps confusing them. When you get a second request—another quiz, calculator, or contact-sales form—you're no longer looking at two unrelated deliverables. You're looking at the same workflow with different campaign content. Look at what's stable across both: - a form - scoring - consent - approved CRM actions - analytics - permissions - accessibility - tests - deployment - failure behavior And what changes every single time: - questions - scoring rules - recommendations - audience - copy - imagery Build the production machinery once, then let each campaign supply its own questions, scoring, recommendations, and design. The next campaign no longer starts with another six-week build. It starts with the shared system you've already built. Start by making ownership explicit. In this specific case: Marketing would control the campaign-specific parts: questions, scoring rules, recommendations, copy, and design. Developers would control the production boundaries: what the system may touch, how it connects, what requires review, and what happens when it breaks. The agent would help marketing work within the capabilities developers have exposed. Agent Native https://agent-native.com/ turns that division of responsibility into code. It's an open-source framework for building applications that people and agents can use together. Instead of treating the interface, the agent, and every outside integration as separate products, it lets them call the same underlying capabilities—while developers keep control of the code and its production boundaries. In the Agent Native framework https://www.builder.io/blog/agent-native-architecture , Actions let you build a capability once and use it everywhere the app needs it. For the quiz, you could build calculateScore , saveResponse , and sendLeadToCRM . The interface and the agent would call those same Actions, and the framework would also expose them to HTTP clients, MCP, A2A, and the CLI. You don't write one backend for the interface, another tool for the agent, and another integration for everything outside the app. When the CRM changes, you update sendLeadToCRM once. Inputs are validated before an Action runs, consequential Actions can require approval, and mutations are recorded automatically. Agent Native also gives coding agents framework-specific instructions and skills, so they can help build Actions using the same patterns instead of improvising the architecture from scratch. Of course, behavior is only half the application. You still need an interface. That's why Agent Native includes working application templates https://www.agent-native.com/templates . These aren't skeletal starter repos or toy demos. They're full applications Builder uses internally and keeps improving in production: Content for Notion- and Docs-style work, Calendar for scheduling, Analytics for dashboards and session analysis, Clips for Loom-style recording, and Forms for Typeform-style intake. It's the idea behind cloneable SaaS https://www.builder.io/blog/the-future-of-saas-is-cloneable : start with the stable machinery of a familiar product category, then shape it around your team's workflow. The templates share a toolkit https://agent-native.com/docs/agent-native-toolkit of reusable product systems for editing, charts, sharing, review, history, setup, observability, and more. The framework handles auth, access checks, persistence, and other runtime concerns underneath them. Remember the quiz from the beginning? It looked finished, but it didn't use any of the company's design-system components. Here, developers connect the shared foundation to the real design system once. Every campaign after that inherits the right form fields, buttons, accessibility behavior, and brand rules instead of handing engineering another almost-shippable interface to rebuild. Marketing still owns what makes the quiz a quiz: its questions, scoring model, recommendations, copy, and campaign-specific design. You just don't have to rebuild the common machinery around it. Sharing a foundation doesn't mean handing everyone the keys to production. Code changes still go through GitHub ownership, branch protection, and review. Access to live systems is managed at the workspace level https://agent-native.com/docs/workspace-management : which apps receive which credentials and integrations, which agents are available, what requires approval, and what gets recorded in the audit trail. That control extends across applications. In a multi-app workspace https://agent-native.com/docs/multi-app-workspace , apps can share identity, permissions, instructions, skills, components, credentials, and genuinely common actions. The quiz can reuse an existing Analytics integration instead of creating another copy. The result is a set of distinct applications built on a shared foundation. Teams can adapt the domain-specific layer, while developers retain control of the system underneath. If one app genuinely needs to diverge, developers can take ownership of the smallest reusable piece instead of forking the entire foundation. Put those pieces together—shared Actions, reusable UI, and developer-owned boundaries—and a third request from your teammate looks very different. The third campaign rolls around. Marketing works directly in the real quiz app. They change the audience, questions, scoring, recommendations, copy, and imagery. The agent can help them, because it's using the same approved actions and the same company context as the UI. Consent, CRM delivery, analytics, permissions, accessibility, tests, and deployment all remain on the path you own. If the campaign needs a new CRM object, you review it, implement it once, and it's done—available to every campaign that needs it. If the campaign just needs a different recommendation for a score of 70, nobody has to file a ticket. Nobody DMs you at 6pm. Meanwhile the compounding works in your favor for once: an accessibility fix improves the shared form everywhere. A rotated credential updates through one shared connection. The next department that shows up starts from the same safe machinery instead of teaching a fresh agent your entire company from zero. The company gets more useful software. You get a better shared system instead of another consolidation project on next year's roadmap. The standard responses to "developers are the bottleneck" are hire more developers or teach everyone to code . Both are slow, and one of them is how you end up with the repo from earlier. There's a third option: keep developers in charge, and change what lands on their desk. Let domain experts shape the real application. Let agents do the repeatable work through actions you defined. Let developers spend their time on architecture, security, integration, failure modes, and things that have never existed before. You're going to own this either way. The only real question is whether you shape the shared capability now, or clean up six disconnected versions of it later.