Great Developer Experience with ngrok founder Alan Shreve
ngrok founder Alan Shreve explains the product work behind “online in one line”: choosing sane defaults, hiding global-network complexity and measuring how quickly a developer reaches the first working request.
Alan Shreve founded ngrok, an ingress platform that can expose a local application to the internet with a single command and is widely recommended in webhook documentation.
Alan describes the tension between simplicity and configurability, how ngrok tests new language libraries, why a tiny public interface can require a sophisticated distributed system, and how hobby use grows into production adoption.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How do you create a simple experience for developers?
Simplicity requires deciding what is truly important, removing unnecessary choices and delaying the rest. Developers simultaneously want software that just works and control over every knob, while each person’s exceptional ten percent differs. A strong product chooses sane defaults for the common path but preserves configuration when the user actually needs it, rather than demanding every decision up front.
How did “online in one line” evolve?
ngrok began as a solo-built executable that created connectivity from a developer’s machine. The same idea expanded into native libraries: an application imports ngrok and receives something that behaves like the language’s normal socket. Keeping that as simple as the command-line experience required repeatedly collapsing configuration and interfaces until the majority use case fit into the smallest useful call.
How do you test an API or library design?
Implementing a proposed interface immediately reveals where it feels wrong, so the team rewrites it repeatedly rather than treating the first design as final. We also become consumers by building on the library ourselves and put early versions in front of community members integrating real applications. Internal use finds friction quickly; outside use catches the sharp edges hidden by our knowledge of the implementation.
Does a simple interface make the underlying system simple?
Usually the opposite. A one-line listener connects into ngrok’s global points of presence, distributes configuration and reloads the edge in real time. The difficult system work is what makes the public interaction feel immediate and obvious. Like one-click checkout, the interface is not simplification by omission; it is complexity deliberately absorbed behind a boundary the user can trust.
How does ngrok make simplicity an organizational priority?
It starts as a product mentality: insist on the minimal interface and make other decisions follow that intention. Then measure the outcome. ngrok tracks time from signup to an application receiving traffic and sees some developers succeed in around 30 seconds. The remaining question is how to bring users who need minutes or hours toward the same moment of value.
How does free hobby use become a commercial customer?
Free developers expose real needs and advance the mission even if they never pay. Commercial use may eventually exceed resource limits, but the more important loop is familiarity: someone solves a webhook problem at home, later recognizes a production connectivity or security problem at work and already trusts ngrok. Product-led growth turns the small magic moment into awareness of a much broader platform.
What larger problem is ngrok trying to solve?
Application developers still work with the assembly language of networking: IP addresses, DNS, certificates, gateways and cloud associations. Ingress as a service places a higher-level abstraction over those primitives, then adds authentication, observation and protection in the proxy layer. The goal is to let a developer focus on business logic and take a weekend application safely into production on Monday.
What lesson should other DevTool founders take from ngrok?
Chase the right abstraction and accept that the route is iterative. A simple surface rarely appears in the first API proposal; it comes from sustained directional alignment, real use and a willingness to remove or postpone choices. The organization must value that work because no isolated process can substitute for repeatedly insisting that the experience become clearer.