About Geodexy
When I joined Spatial Networks we were in the very early stages of building a data collection tool, primarily for internal use to improve speed and efficiency on data project work. That product was called Geodexy, and the model was similar to Fulcrum in concept, but in execution and tech stack, everything was completely different.
A few years back, CEO Tony Quartararo wrote up a retrospective post detailing out the history of what led us down the path we took, and how Geodexy came to be:
After this experience, I realized there was a niche to carve out for Spatial Networks but I’d need to invest whatever meager profits the company made into a capability to allow us to provide high fidelity data from the field, with very high quality, extremely fast and at a very low cost (to the company). I needed to be able to scale up or down instantly, given the volatility in the project services space, and I needed to be able to deploy the tools globally, on-demand, on available mobile platforms, remotely and without traditional limitations of software CDs.
Technology and go-to-market strategy
Tony’s post was an excellent look back at the business origin of the product — the “why” we decided to do it piece. What I wanted to cover here was more on the product technology end of things, and our go-to-market strategy (where you could call it that). Prior to my joining, the team had put together a rough go-to-market plan trying to guesstimate TAM market fit, customer need, and price points. Of course without real market feedback (as in, will someone actually buy what you’ve built, versus say they would buy it one day), it’s hard to truly gauge the success potential.
Back then, modern web frameworks in use today were around, but there were very few and not yet mature, like Rails and its peers. It’s astonishing to think back on the tech stack we were using in the first iteration of Geodexy, circa 2008. That first version was built on a combination of Flex, Flash, MySQL, and Windows Mobile(1). It all worked, but was cumbersome to iterate on even back then. This was not even that long ago, and back then that was a reasonable suite of tooling; now it looks antiquated, and Flex was abandoned and donated to Apache Foundation a long time ago.
Initial success
We had success with that product version for our internal efforts. It powered dozens of data collection projects in 10+ countries around the world, allowing us to deliver higher-quality data than we could before. The mobile application (which was the key to the entire product achieving its goals) worked, but still lacked the native integration of richer data sources — primarily for photos and GPS data. The former could be done with some devices that had native cameras, but the built-in sensors were too low quality on most devices. The latter almost always required an external Bluetooth GPS device to integrate the location data. It was all still an upgrade from pen, paper, and data transcription, but not free from friction on the ground at the point of data collection.
Being burdened by technology friction while roaming the countryside collecting data doesn’t make for the smoothest user experience or prevent problems. We still needed to come up with a better way to make it happen, for ourselves and absolutely before we went to market touting the workflow advantages to other customers.
2009 update
In mid-2009 we spun up an effort to reset on more modern technology we could build from, learning from our first mistakes and able to short-circuit a lot of the prior experimentation. The new stack was Rails, MongoDB, and PostgreSQL, which looking back from 10 years on sounds like a logical stack to use even today, depending on the product needs. Much of what we used back then still sits at the core of Fulcrum today.
We never developed a modern mobile client for Geodexy’s data collection piece. Back then, the App Store was still in its early days, and the Android Market was also immature. We didn’t have the resources to develop two mobile clients from the start. Interestingly, we had a functioning Blackberry app first, highlighting how different the mobile platform landscape was a decade ago.
On the other hand, Geodexy’s iOS app showed us the potential that iOS development offered. One of our developers, familiar with C++, learned Objective-C in a few months. He then created a fully functional app with offline support, automatic GPS integration, and photo capabilities. This new wave of platform features, including a REST API, online form designer, and iOS app, enhanced our Foresight data collection efforts. We knew it had long-term potential if we could productize it correctly.
However, we didn’t advance much further with the Geodexy platform before shifting our SaaS focus. We redirected our efforts to a new product concept aimed at the property inspection business.That’s what led us to launch allinspections, which I’ll continue the story on later.
In hindsight
It’s satisfying to reflect on past challenges and how they differ from today’s concerns. We focused heavily on tech stack and implementation, which, in the long run, aren’t crucial to a business idea’s success. We didn’t prioritize market analysis, pricing, or early customer development as much as we should have. Part of this came from prioritizing internal project support and lacking go-to-market experience in SaaS. However, those lessons became invaluable for future product efforts and still inform our decisions today.
- As painful as this sounds we actually had a decent tool built on WM. But the usability of it was terrible, which if you can recall the time period was par for the course for mobile applications of all stripes.
- That was a decade ago, man.
This post originally appeared on colemanm.org. You can read the first post in this series, describing my own entrance into product development and management, here.