Developer Experience Lessons From Building an AI Travel Platform

Our first external developer integration took three weeks. The developer was patient, technically strong, and motivated. It still took three weeks because our API had no SDK, our documentation was a shared Google Doc, our error messages said "Internal Server Error" for everything, and our sandbox did not exist yet.

Our most recent integration took three hours. Same type of developer. Same complexity of integration. The difference was eighteen months of deliberate DX investment.

Here is what we learned along the way: what worked, what we should have done differently, and what surprised us about building developer tools for an AI travel platform.

The timeline

Month 1: API design. We spent the first month on API design before writing any developer-facing tools. Resource-oriented endpoints. Consistent response envelopes. Typed error codes. This was time well spent. Bad API design is expensive to fix later because every tool built on top of it inherits the problems.

Month 3: SDK. We shipped a single typed language across the stack and Python SDKs. These immediately reduced integration time because developers could work with typed objects instead of raw HTTP responses. The SDKs also forced us to improve our API design -- writing the SDK revealed inconsistencies that were invisible when we were only testing with cURL.

Month 6: CLI. We shipped the command-line tool. I am going to argue this was our most valuable DX investment, which surprised us. The CLI was intended as a convenience tool. It turned out to be our most effective API design feedback mechanism because every engineer on our team used it daily and complained loudly when something was awkward.

Month 9: Dashboard. The developer dashboard came last, after the SDK and CLI. This ordering was intentional. We wanted to solve the developer's needs in the tools they already used (their code editor and terminal) before building a separate web interface.

Month 12: Doc testing and analytics. We started testing our code examples in CI and building the analytics dashboard for API consumers. These were the "maturity" investments that compound over time.

What worked

Investing in error messages early. We made error message quality a priority from month one. Every error has a specific code, a human-readable message, a details field with context, and a link to documentation. This single investment reduced support tickets by 60-80% from our early baseline and is, by ROI, the best DX decision we made.

Building the CLI before the dashboard. The CLI caught more API design issues than the dashboard ever would have. Terminal interactions are constrained -- you cannot hide a confusing API behind a pretty UI. If the CLI workflow feels awkward, the API design needs improvement. The CLI was our canary in the coal mine for API quality.

Schema-first design. We wrote our OpenAPI specification before writing endpoint implementations. The spec was the contract. SDKs were generated from it. Documentation was generated from it. Tool schemas for AI agents were derived from it. This meant every consumer of the API benefited from a single source of truth.

What we would change

Ship doc testing earlier. We did not start testing documentation examples in CI until month 12. During the preceding months, examples silently drifted as the API evolved. Developers hit broken examples and either filed tickets or silently gave up. Starting doc testing in month 3 alongside the SDK would have prevented months of accumulated drift.

Start community building sooner. We launched our community channels at month 10. By then, our earliest developers had already formed habits of emailing support directly. An earlier community launch would have created a peer-support channel that reduced support load and built advocacy from the start.

Invest in onboarding analytics earlier. We did not instrument the quickstart funnel until month 8. Before that, we had no data on where developers dropped off during onboarding. We were improving the quickstart based on intuition, which was sometimes right and sometimes wrong. Data would have made every improvement more targeted.

What surprised us

AI agents became API consumers faster than expected. We designed our API for human developers. Within six months, a significant and growing portion of our traffic was coming from AI agents built by those developers. The agents cared about schema quality more than documentation quality. They needed deterministic responses more than friendly error messages. They needed tool schemas that described capabilities precisely.

This shifted our priorities. We started investing in tool schema quality, agent-specific sandbox features, and deterministic test fixtures. The AI-agent traffic is now growing faster than direct developer traffic, which validated the investment in schema-first design retroactively.

CLI usage predicted dashboard feature requests. Features that engineers asked for in the CLI showed up as dashboard feature requests three to six months later. Log searching, webhook debugging, and metric alerts all appeared in CLI requests first and dashboard requests second. The CLI user base was our early adopter community for DX features.

Error message investment had the highest measurable ROI. We ranked our DX investments by measurable return. Error messages came first by a wide margin. CLI second. SDK third. Doc testing fourth. Dashboard fifth. The ordering surprised us because dashboards feel like the "big" investment and error messages feel like a detail. But the detail is what developers interact with hundreds of times per day.

Advice for early-stage platforms

If I could go back and give our month-one selves advice, it would be five investments in priority order.

First: API design. Get the resource model, response envelope, and error taxonomy right. Everything else builds on top of this. Changing it later is painful.

Second: error messages. Every error code with a specific message, details, and documentation link. This prevents more support tickets than any other single investment.

Third: SDK in your primary audience's language. For us, that was a single typed language across the stack. One good SDK is better than three mediocre ones. Expand to other languages as demand warrants.

Fourth: CLI. A simple CLI that can search, list bookings, and tail logs. Your team will use it daily and catch problems before external developers do.

Fifth: quickstart with instrumentation. A six-step quickstart that you can measure. Know where developers drop off. Fix the drop-off points.

Everything else -- dashboard, analytics, community, advanced docs -- builds on top of these five. Get the foundation right, and the rest follows naturally.

Nowah is positioned as the developer platform for AI-native travel. DX is not a nice-to-have for us. It is the product moat. The lessons from eighteen months of building developer tools are embedded in everything we ship, and they will continue to shape every decision we make.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.