Why We Built drio

We built drio because the standard was arriving faster than the workflow. MCP made AI apps feel real. Actually shipping one still felt like a custom backend project.

That mismatch kept bothering us. Anthropic introduced the Model Context Protocol on November 25, 2024. The official MCP site framed it with the right mental model fast: a shared way for AI applications to connect to external systems. Then OpenAI launched apps in ChatGPT on October 6, 2025, said developers could build on MCP, and said the Apps SDK could reach over 800 million ChatGPT users. On December 17, 2025, OpenAI opened app submissions for publication in ChatGPT. At the same time, Similarweb said in its December 2, 2025 report that Gen AI average monthly visits grew 76% year over year and AI platforms drove more than 1.1 billion referral visits in June 2025, up 357% year over year. Different sources, same message: the platform shift was no longer hypothetical.

So yeah, the signal was real. The part that still felt broken was the build experience.

The part that suddenly felt real

There were a few moments where this stopped feeling like "interesting protocol news" and started feeling like an actual product category.

First, MCP gave the ecosystem a real shared contract. Not perfect. Not fully uniform across hosts. But real.

Second, distribution showed up. Once ChatGPT started treating apps as something that could live inside a conversation instead of outside it, the question changed. It was no longer just "can we connect a tool?" It became "what kind of app should this feel like when someone uses it in chat?"

Third, the ecosystem attention got hard to ignore. The official reference servers repository now shows more than 85,000 GitHub stars. That number is not the product. It is just a good proxy for how many developers are circling the same shift at the same time.

That part mattered. It meant we were no longer waiting for the protocol layer to exist. It already existed. The distribution layer was starting to exist too.

The part that still felt painful

The protocol was not the real problem.

The workflow was.

Even when the use case was obvious, the first build still tended to look like this:

• define tool schemas carefully enough that the model can use them
• connect and test upstream APIs
• decide what the response should look like for a human, not just a model
• handle auth and deployment
• test the result in the target client
• then redo parts of it because the host experience was slightly different than expected

For an engineering-heavy team, that is survivable. For a mixed team where product, GTM, ops, or design already know exactly what the assistant should do, it becomes a bottleneck fast.

That was the recurring feeling for us: the app idea was usually the easy part. The surrounding assembly work was what slowed everything down.

The workflow gap we kept seeing

We kept seeing the same pattern.

A team would know the workflow they wanted:

• help prospects compare plans
• answer common implementation questions
• show account status in chat
• turn product results into something easier to browse

But getting from that idea to a real app still meant too much protocol knowledge, too much runtime setup, and too much one-off glue.

That gap is why MCP alone did not feel like the whole answer.

MCP solves a real portability problem. It gives hosts and servers a clearer way to talk. It does not automatically make app creation feel reviewable, collaborative, or fast for the people who actually understand the workflow best.

That was the missing layer we cared about.

What we thought should be easier

The question we kept coming back to was pretty simple:

What if building an AI app felt less like assembling protocol plumbing and more like configuring a product?

Not "make it magic."

Not "hide the hard parts and hope nobody notices."

Just make the core loop much clearer:

1. define the tool
2. connect the system it depends on
3. choose the interface the user actually needs
4. preview it
5. publish a real endpoint

That is the loop we wanted for ourselves.

It is also the loop we thought would let more teams participate in the shift without pretending everyone suddenly needed to become an MCP specialist.

Why we did not want to stop at code generation

There are a few ways to lower the barrier here.

One path is code generation. That can be useful. We are not against it. It is a good fit for some teams, especially when the end goal is still an engineering-owned codebase.

But generated code does not remove ownership. It mostly changes when you pay for it.

You still own:

• the generated server
• the deployment path
• the maintenance surface
• the review burden
• the drift between what the workflow was supposed to do and what the code now does

That is why a builder with a real runtime behind it made more sense to us.

We wanted the app definition itself to stay visible:

• the tools are explicit
• the data sources are explicit
• the response format is explicit
• the launch surface is explicit

That visibility matters more than people think. Product can review the app. GTM can review the language and user path. Engineering can review auth, upstream systems, and rollout risk without reverse-engineering an invented codebase first.

What drio became

drio is our attempt to make that workflow usable.

At a high level, the product is built around one idea: your team should be able to define tools, connect APIs, map results into the right widget, preview the experience, and publish a live MCP endpoint without rebuilding the whole stack from scratch every time.

The current docs reflect that shape pretty directly:

• How drio Works explains the runtime model in plain language
• Launch Your First App focuses on the first useful launch
• MCP endpoint shows how the published endpoint is used in target clients
• Choose The Right Response Format focuses on the widget layer

That product shape was intentional.

We did not want drio to be a marketing wrapper around "write the hard parts yourself later." We wanted a real builder workflow with a real runtime: tool definitions, widget rendering, branding, preview, and a live endpoint that AI clients can actually call.

If you want the product introduction version of that story, read Welcome to drio. If you want the broader category framing, Build AI Apps Without Code is the better companion piece.

What still should not be automated away

This part matters a lot to us.

We do not think every part of shipping an AI app should disappear behind a builder.

Some things should stay explicit:

• which systems the app is allowed to access
• whether the data is public, shared, or user-specific
• what level of review is required before rollout
• when engineering should step in

That is why the handoff points in the docs stay visible. The builder should remove repetitive assembly work. It should not erase the judgment needed for auth, security, or production rollout.

That split is part of why the product feels practical for mixed teams instead of only aspirational.

Why now felt like the right time

Timing was a big part of the decision.

Before MCP, there was no obvious shared protocol to build around. Before apps in ChatGPT and similar host experiences matured, there was less reason to care about a reusable runtime and interface layer. Once both started moving, the gap became hard to ignore.

By late 2025, the category had three things we thought were finally durable enough to build on:

• a serious open protocol
• real host distribution for connected AI apps
• clearer demand for structured, chat-native interfaces instead of plain text alone

That was enough for us to stop treating this like a future bet.

Where we are now

Right now, the most useful role for drio is not "replace all engineering."

It is this:

help more teams get from idea to a real first launch without turning the first build into a full custom platform project.

That includes:

• early pilots
• internal tools
• chat-native product experiences
• connected reporting flows
• support, qualification, and discovery workflows

And the honest traction signal we care about most right now is not some inflated headline metric about ourselves. It is that the workflow is real enough to be used, reviewed, and tested end to end:

• a visual builder instead of a blank server
• a widget layer instead of plain-text-only responses
• a publishable MCP endpoint instead of a prototype that stops at mockups
• docs that make the handoff boundaries explicit instead of hand-wavy promises

That is the phase we are in, and frankly it is the right phase to be in. The product has to earn trust by making the build loop clearer before it earns trust through bigger claims.

The long-term belief is still the same one that started the product: AI apps should be easier to build than they are today, and the teams closest to the workflow should be able to shape them directly.

If you want to see the workflow in practice

Start with Launch Your First App if you want the fastest practical path. If you want the fuller step-by-step API tutorial, go to Connecting Your First API. If you want the product architecture first, How drio Works is the better entry point.

Summary

We built drio because MCP made the ecosystem legible, but not yet simple enough for most teams to build with directly. The protocol solved a real problem. The workflow still felt too infrastructure-heavy, too code-first, and too fragmented across tool definition, UI, deployment, and client testing.

drio is our attempt to close that gap. Not by pretending the hard parts do not exist, but by making the actual build loop clearer, more reviewable, and more accessible to the teams that already know what they want to ship.

FAQ

Why did you build drio instead of just writing more MCP code?

Because writing MCP code was not the main problem we wanted to solve. The larger problem was that every new app still required too much surrounding setup for teams that mainly wanted to define tools, connect systems, and ship a usable interface.

Is drio for non-technical teams only?

No. It is meant for mixed teams. Non-technical teammates can shape the workflow and interface, while technical reviewers still keep control over auth, system access, and rollout.

Does drio replace custom MCP development entirely?

No. Some apps still need code-first development, especially when the hard part is custom server logic, unusual auth, or strict infrastructure control. drio is strongest when the value is in the tool design, connected data, and interface workflow.

Why build around MCP specifically?

Because MCP is the clearest shared protocol layer the ecosystem has for this category today. It gives apps a more portable way to expose tools, resources, and prompts across hosts instead of starting from a different integration model every time.

What is the best next step after reading this?

If you want the product overview, read Welcome to drio. If you want the category view, read Build AI Apps Without Code. If you want to see the workflow directly, start with Launch Your First App.