The B-Bark GPS Platform: From Side Project to Acquisition

The Origin

It's the autumn of 2008. I'm in a forest somewhere in northern Finland, it's getting dark, and I have no idea where my dog is. This is not a metaphor. Birch hunting in Finnish forests means the dog is working independently, ranging hundreds of metres through dense trees, following scent trails across terrain that has no visibility beyond twenty metres in any direction. Commercial GPS collars existed — there were a couple of products on the market — but they were expensive, had update intervals of 30 seconds or more, and the software was a basic web interface that showed you a dot on a raster map from 2004. You'd see where the dog had been two minutes ago, not where it was now.

I drove home with the dog eventually located by sound. That winter I started building something better.

Building Version 1

The first version of what became B-Bark was an embarrassingly direct solution to a specific problem. I bought GPS modules from a Chinese supplier, a GSM modem, and a microcontroller dev board. The "collar" was a small waterproof case zip-tied to the dog's tracking collar that sent a UDP datagram containing GPS coordinates every 5 seconds to a server I was running. The server stored the coordinates and served them to a web frontend I built in PHP. The frontend showed a trail of dots on an OpenStreetMap map, refreshing every 10 seconds.

Total cost of the prototype: about 80 euros in hardware plus several evenings. Battery life: about 6 hours, which was enough for a hunting day. Accuracy: within 5–10 metres in open terrain, degraded under dense canopy. Update rate: 5 seconds, compared to the 30-second commercial products.

I tested it with my own dog through the winter hunting season and it worked. Not elegantly — the waterproofing was improvised, the battery case was held on with gaffer tape — but it worked. I started showing it to other hunters at local club events in late 2009. The response was immediate and clear: people wanted this.

First Commercial Customers

Word spread through hunting clubs faster than I had infrastructure to support it. By mid-2010 I had about forty units in use, built by hand in my workshop, running on a backend that was one server process away from losing everyone's data. The "subscription" was an informal arrangement: I charged enough to cover hardware costs and a small margin, and people paid it cheerfully because the alternative was worse.

The online hunting forums were the key distribution channel. Finnish hunting forums have a culture of extremely detailed equipment discussion — the kind of community where someone will write a 3,000-word review of a scope mount. B-Bark threads accumulated quickly. People posted field reports, compared update rates against commercial units, posted screenshots of their dog's track across familiar terrain. Each thread drove several new users. I didn't do any marketing; the product did it for me.

The first real infrastructure crisis came in November 2010, when forty simultaneous users during opening day of the pheasant season overwhelmed the server. The backend went down for two hours during prime hunting time. I got forty angry emails. I spent that evening on a bare-metal server migration that I should have done two months earlier. This is a lesson I have subsequently applied professionally: load test before opening day, not on it.

Platform Growth

Between 2010 and 2015, B-Bark grew from forty users to several hundred, then into the low thousands. The hardware moved from hand-assembled prototypes to a contract manufacturer in Tampere. I introduced subscription tiers: a basic tier with 10-second updates and 7-day track history, and a premium tier with 3-second updates, longer history, and multi-dog support for hunting parties.

The mobile app came later than it should have, in 2012. I built Android-first because that was the Finnish hunting demographic — roughly 70% Android when I surveyed users. The iOS app came a year later and immediately attracted complaints about feature gaps that I couldn't close quickly enough as a solo developer. Mobile app development while maintaining a backend while holding down a full-time job while trying to have a family is, I can report, not a sustainable model.

Managing cloud infrastructure as a side project has a specific challenge: the production system is always a concern, even when you're not working on it. A PagerDuty alert at 2am during hunting season, six months after you thought you'd fixed the connectivity issue with that one batch of GSM modems, remains in my memory as one of the more vivid operational experiences of that period. You cannot deprioritise a production incident because it's inconvenient timing. The dog is in the forest.

The Technical Debt Was Inevitable

If you read the B-Bark codebase in 2015 with fresh eyes, you would find two systems occupying the same repository. One was architecturally coherent — the GPS ingestion backend, the WebSocket real-time update pipeline, the device management infrastructure — built during periods when I had time to think. The other was a collection of "I just need this to work tonight" patches: the billing integration that used a third-party webhook handler because I didn't want to build a proper payment flow, the notification system that was actually a cron job that checked a database table every 30 seconds.

I don't regret this. The patches kept the product running for users who were in the field and needed it to work. But I was also honest with myself about what the codebase was becoming: a system that I could maintain indefinitely because I had deep context on all of it, but that would be very difficult for anyone else to understand or extend. The bus factor was exactly one. If I had been incapacitated for a month, B-Bark would have had problems within two weeks.

This is the fundamental tension of the engineering side-project: you're optimising for "works for users" under the constraint of "available time is severely limited," and the result is a system that serves its primary function excellently while accumulating structural debt in everything adjacent to that function. The GPS tracking worked. The ops tooling, the admin interfaces, the billing reconciliation — these were archaeological artefacts of whatever I had time to build when I built them.

The Acquisition Decision

I was not looking to sell B-Bark. In 2019 I received an approach from a company with established distribution in the Nordic hunting equipment market. They had physical retail relationships I could never build, a customer support organisation, and an existing user base that overlapped with B-Bark's target demographic. Their existing GPS product was technically inferior to B-Bark. The conversation they opened was essentially: your technology plus our distribution.

I thought about this for longer than I would like to admit. The objections were real:

• I had built this myself. The prospect of it becoming someone else's product, possibly with decisions I would disagree with, was uncomfortable.
• The recurring subscription revenue was modest but real, and growing.
• I had become genuinely attached to the user community.

The arguments for were also real:

• The hardware supply chain was getting more complex, not less. Component lead times had extended significantly after 2018. I had no purchasing leverage as a small operation.
• The customer support burden was scaling in ways my evenings couldn't match. I was regularly spending 3–4 hours per week on support tickets that a dedicated team could handle properly.
• The acquirer had the infrastructure to actually take the product to market in Sweden and Norway, which I had planned to do for three years and had not done.
• The timing in my career was right. I was moving into a more senior leadership role at Vincit, and the cognitive overhead of maintaining a live commercial product alongside that was real.

The price was fair. Not dramatic, but fair. I accepted.

The hardest part of the acquisition wasn't the decision or the negotiation. It was writing the handover documentation — the first time I had to explain the whole system to someone else, and discovering how much of what I "knew" existed only in my head.

What I Kept

The GPS backend architecture patterns transferred directly to subsequent work. The IoT fleet management problems — device authentication, firmware update distribution, handling devices that go offline unexpectedly, reconciling position data from devices with intermittent connectivity — are not unique to hunting dog tracking. They're general problems in any IoT deployment, and having solved them from scratch with real production stakes gave me an understanding of the failure modes that I don't think I could have acquired any other way.

The specific understanding of what happens to a UDP datagrams-based ingestion backend when 300 devices reconnect simultaneously after a cellular network outage, for instance, is not in any textbook. You learn it by watching your backend fall over and reading the logs. I have learned it. I won't forget it.

The product management instinct also stayed. Running B-Bark alone meant being simultaneously the product manager, the backend engineer, the mobile developer, the customer support team, and the on-call engineer. The decisions I made about what to build and what to defer were made with complete context and direct accountability. The feature request that a user emailed me on Monday was one I'd built or deferred by Friday, with full knowledge of the tradeoffs. This is not how product development works in larger organisations, and I think the B-Bark experience made me permanently better at the prioritisation part of engineering leadership — more honest about real tradeoffs, less susceptible to feature request pressure for its own sake.

What I Miss

The directness. You build something. You ship it. Two days later a hunter in Oulu sends you a message saying the new 3-second update interval made it possible to locate his dog in a marsh that would previously have been a search. That feedback loop — from code to deployed software to real use by a specific person whose specific problem is now solved — is extremely short with a solo product and extremely long in enterprise software.

I don't spend time thinking about whether I should have kept B-Bark longer or sold earlier. The timing was right when it happened. But I keep the user feedback emails in a folder, and I occasionally read one from someone who found their dog because the tracking worked at the moment it mattered. That's the thing you're building for, in the end.