PathVynt turned five years old this year. We started building it in Mountain View in 2021 with no external funding — no seed round, no angels, no accelerator. We funded the first 18 months of development from consulting revenue from robotics companies that had the same perception plumbing problems we were trying to solve, which turned out to be a reasonable way to build a product: your customers are also your test environment.
This post is not a self-congratulatory reflection on how hard bootstrapping is. It's a more specific set of observations about what building a robotics SDK without a funding runway forces you to get right that you might otherwise defer, and what it lets you get wrong by not deferring.
Scope discipline is not optional
The most consistent mistake I see early robotics software companies make is building a general perception platform rather than a specific, narrow product. The pitch for generality is obvious: a larger addressable market, more defensible IP, more value to offer customers. The problem is that in perception software, generality means "it works in some conditions for some robots" rather than "it works reliably in production conditions for a specific class of robots."
We made this mistake in 2022. For about four months we tried to support five sensor modalities — LiDAR, stereo camera, monocular camera, radar, and ultrasonic — simultaneously in the fusion engine. The resulting code was complex, the test matrix was enormous, and every new hardware combination uncovered a new edge case. The fusion worked in controlled conditions and broke in subtle ways in the field. We dropped radar and ultrasonic support entirely, tightened the camera support to LiDAR + mono and LiDAR + stereo only, and the code immediately became maintainable and reliable.
The PathVynt platform page says we support three sensor modalities. That's not because three is the technically achievable limit — it's because three is the number we can support with a four-person team at production quality. Every robotics SDK should have a very public answer to the question "what sensor combinations do you actually not support?" Most don't, because the sales team doesn't want to say no to anything. Bootstrapped teams don't have that luxury.
Integration ergonomics compound over time
The first version of PathVynt's C++ API was designed by a robotics engineer (me) who spent most of his time thinking about sensor fusion, not API design. The result was a technically correct but ergonomically hostile API: eleven configuration parameters required before initialization, no sensible defaults for common configurations, and error handling that returned integer status codes that callers were expected to check manually.
We rewrote the initialization model completely in v1.2 — introducing the configuration preset system (WAREHOUSE_INDOOR, OUTDOOR_URBAN, HIGHWAY_TRUCK, etc.) and making sensible defaults for all non-critical parameters. Integration time for a new customer dropped from approximately 3 days to approximately 4 hours. This matters not just for customer experience but for our own support load: a longer integration time means more debugging sessions, more "why isn't this working" emails, more engineering time spent on support rather than on the product.
The lesson: API ergonomics are not a luxury polish item for when you have spare engineering time. They directly affect your support cost, your customer's time-to-value, and whether engineers at prospective customers form a positive first impression when they run the quickstart. Prioritize them earlier than feels justified.
Docs are load-bearing
There's a common implicit assumption in early-stage software companies that docs can be written when you have time, updated when the feature settles, and improved when you hire a technical writer. For a B2B SDK company selling to robotics engineers, this is wrong in a specific way: a robotics engineer evaluating your SDK will read your docs before your sales team can schedule a call. The docs are the product evaluation.
We track which docs pages are visited most frequently during the pre-signup evaluation period. The quickstart guide and the API reference together account for 65% of sessions from new visitors. If either of those is incomplete, inaccurate, or assumes knowledge that isn't stated, the evaluation ends there. The engineer doesn't send a confused email — they close the tab.
PathVynt docs have three rules that we've maintained since v1.1: (1) every documented parameter has a stated valid range and a stated default. (2) every performance claim in the docs cites the hardware and configuration it was measured on. (3) every page has a "what this doesn't do" section that documents known limitations and unsupported use cases. The third rule is the most important and the hardest to maintain, because it requires saying "no" in public and resisting the temptation to remove it when the sales team pushes back.
Customer prepayments are not a compromise
We funded our first two feature development cycles — the occupancy grid engine in v1.1 and the localization module in v1.2 — through prepayment agreements with two early customers who needed those features for their deployments. They paid us a fixed fee for the development work and received early access to the features when they shipped.
Some founders I talk to are uncomfortable with this model because it feels like consulting rather than product development. I'd push back on that framing. The alternative funding source — external investment — requires giving up equity and accepting someone else's roadmap priorities. Customer prepayment means the person funding the feature development is the person who will use it in production. Their feedback during development is direct and specific. The features they fund are the features their production environment actually needs, not features that are strategically compelling to investors with no direct exposure to robotic deployments at -18°C.
PathVynt would not have built cold-storage thermal calibration correction in 2022 without a customer deploying in a freezer environment. It would not have built the OEM redistribution license structure without a customer trying to ship our SDK inside their product. External funding might have let us build more features faster. It would also have let us build features that robotics teams deploying in real environments don't actually need.
What independent funding means for buyers
Robotics companies evaluating infrastructure software care about longevity. Will this vendor exist in three years? Will the SDK API be stable? Will support be available when we hit a hard edge case at 2am before a customer demo?
The honest answer for us: we are a small, independently funded team, and we have been profitable on an operating basis since 2023. We are not growing at a rate that requires external capital to sustain. This means our roadmap is driven by what our customers need to ship, not by investor pressure to expand into adjacent markets or hit growth metrics. It also means we are not building toward an acquisition or an IPO exit that would likely result in the SDK being deprecated or absorbed into a larger platform.
We can't claim the stability of a large infrastructure vendor. We can claim that the decisions we make about the product are made by engineers who write the code and talk to the customers, not by a board room. For the teams who have found that to matter in practice, it's been worth the trade-off.
