We started Proximarun in 2023, and we are writing this after about two years of building an infrastructure product with no outside funding. This is not a "how to get VC attention" post. It is an attempt to write down what we actually learned building a technical product for a technical audience as a team of two, mostly from the lessons that cost us time we did not have.
Infrastructure products are a particular kind of hard to build as a small team. The trust bar is higher than it is for SaaS tools that live on the side. When someone routes their AI inference traffic through your system, a bug in your routing logic is their production incident. That dynamic shapes everything from how you write documentation to how you handle your first support request.
The Customer Who Actually Converts First
Early on, we had a mental model of our target customer that was too broad. We imagined any team running AI inference who cared about cost or latency. In practice, the first people who actually integrated Proximarun in year one were a specific subset: platform engineers and ML infra leads at growing companies who had recently hit a specific inflection point. They had gotten past the "one API call, one model" stage and were managing a node pool with at least 2-3 different backends or node types. They had started feeling the pain of static routing but had not yet hired a dedicated infra engineer to build something custom.
The companies where the CEO or a product person was evaluating infrastructure tools tended to move slowly or not at all. The individual engineers who had direct ownership of the inference stack and a specific pain they could articulate moved quickly. We started paying attention to who was opening the docs versus who was sitting in a demo, and adjusted accordingly.
If you are building a technical infra tool and trying to find your early adopters: look for the person who already has the problem at hand and is about to solve it manually. They will evaluate your tool with the urgency of someone about to write code they do not want to write. That is the evaluation window where you win.
What Documentation Actually Does
We rewrote our quickstart guide three times in year one. The first version was correct but explained things in the order we found logical as the builders. The second version was more organized but still failed in a specific way: it assumed the reader already had a mental model of what a routing layer does and why they need one.
The version that actually converted readers into integrators started by describing the problem precisely, in the same language the reader would use when filing a ticket about it. "You have three inference endpoints. You wrote a routing script. It works until it does not, and debugging it at 2am is not fun." Then it showed what the integration looks like, then the first working call, then the more advanced configuration.
For an infrastructure tool, documentation is also where you establish trust before anyone has run your code in production. A quickstart that is vague or that hand-waves over error states signals that the product itself might behave the same way. Engineers evaluate the quality of documentation as a proxy for the quality of the engineering. This is not always fair, but it is real. We have had people explicitly mention the docs quality in integration notes.
The other documentation lesson: write the failure modes. Not the happy path. Any tutorial can show you what happens when everything works. Engineers who are evaluating whether to trust your system with production traffic want to know: what happens when a node is unhealthy? What happens if the routing decision itself fails? What is the fallback behavior? If your docs do not answer those questions, the evaluation stalls.
The Feature Backlog Problem
In the first six months, we had a backlog of about 40 feature ideas. Many of them came from conversations with potential users who said things like "it would be great if it also did X." We built several of them. About half of those were wrong.
The pattern we eventually recognized: when an engineer describes a feature they want, they are often describing a solution to a specific problem they have in their current environment, not a general capability they would use if their environment were different. "It would be great if Proximarun could also handle model versioning" is not a request for a model versioning feature. It is a signal that this person has a model versioning pain that they are hoping to offload. The right response is to ask what they are doing today, not to go build a model registry.
We stopped building features in response to one-off requests and started building features when three or more distinct teams described a similar friction point using similar language without prompting from us. That bar is higher and takes longer to hit, but the features we built under that constraint actually got used.
Operating Without a Sales Motion
We do not have a sales team. We do not do outbound. Every team using Proximarun found us through the docs, this blog, or a referral from an engineer who had already integrated. That is a slow initial ramp. It is also the only distribution model we could sustain as a bootstrapped team, and it has some properties that outbound sales does not: the teams who arrive this way have already made up their mind that they need the tool. The evaluation is about fit, not persuasion.
The downside of this model is that you can spend a long time at low volume without a clear signal of whether the product is working or whether the distribution is simply too narrow. We use trial-to-paid conversion rate as our primary product health signal rather than raw signups, and we track qualitative feedback from teams who tried and did not convert just as closely as the ones who did.
One observation about bootstrapping specifically: the absence of external funding pressure creates a different relationship with product decisions. We do not have quarterly targets that push us toward features that look good in demos but do not solve real problems. We can spend a month improving reliability and documentation with no new features and feel fine about it. That is not a virtue claim, it is just a structural property of not having investors who need to see growth on a schedule. Whether that tradeoff makes sense depends entirely on your cost structure and how fast your market is moving.
What Year Two Looks Like
We are not going to claim we figured it all out in year one. We made expensive bets on features that did not land, we underinvested in observability tooling that would have helped our users debug faster, and we spent too long on a UI that engineers were not actually using before we deprioritized it.
The through-line from year one that we are carrying forward: specificity wins. A narrowly defined tool that solves a specific problem better than a general tool or a hand-rolled script will find its users. The users it finds will be the ones who actually have that problem, which means they will use it in production rather than just trying it. That is the only adoption that matters for an infra product that needs to prove it is reliable.
The trust bar never gets lower. It just gets easier to clear once you have evidence of working in production at real scale. That evidence is the thing you are building toward in year one, even when it does not feel like it.