Geospatial Product Swiss Army Knife

1. The “Build It and They Won’t Come” Trap

We have all seen it: a talented geospatial professional spends months—perhaps years—perfecting a technically sophisticated web map or a niche data service, only to release it to a deafening silence. In our industry, the “build it and they will come” philosophy is a fast track to zero traction.

Precision is the enemy of progress when it is applied to the wrong problem.

Daniel and Stella Blake Kelly explored a remedy for this pattern. Stella—a New Zealand-born, Sydney-based strategist and founder of the consultancy Cartisan—didn’t start with a master plan. She “fell into” the industry after being inspired by a lecturer with bright blue hair and a passion for GIS that rivaled a Lego builder’s creativity. Today, she helps organizations move from “making things” to “building products that matter” using a framework she calls the Product Swiss Army Knife.

2. The 7-Step Framework: More Than Just a Map

Many geospatial experts suffer from a technology-first bias, prioritizing data accuracy over strategic utility. To counter this, Stella advocates for a disciplined, seven-tool toolkit designed to bridge the gap between GIS and Product Design:

1. Vision: Establish a clear statement of what you are building and why it needs to exist.
2. User Needs: Move beyond assumptions to identify real users and their specific friction points.
3. Market & Context: Analyze the existing ecosystem (competitors, data, and workflows) to find your gap.
4. Features: Ruthlessly prioritize “must-haves” to define a lean Minimum Viable Product (MVP).
5. Prototypes & User Flows: Map out the user’s journey through the service before writing a line of code.
6. Proof of Concept: Create a tangible, working version to prove the technical and market logic.
7. Launch & Learn: Release early to gather real-world data and iterate based on evidence.

This structure forces builders to treat the “spatial” element as a solution rather than the entire product. To illustrate User Needs (Tool #2), Stella suggests using formal User Stories to step out of the technical mindset:

“As a solar panel marketer, I want to find potential customers with enough roof surface area so that I can reach out to them and provide an accurate quote.”

By grounding the project in a specific human problem, the developer stops building for themselves and starts building for the market. As Stella notes:

“The thing about the product Swiss Army knife… is that it can be applied to almost any situation where there is an end consumer, where somebody is going to use the thing, the service that you make.”

3. The “200 Tools” Strategy: Programmatic Market Validation

Daniel shared an unconventional approach to product discovery that serves as a masterclass in Market Context (Tool #3). Leveraging AI, he has built nearly 200 simple geospatial tools—such as a “Roof Area Calculator”—not as final products, but as a “sandbox” for discovery.

This is Programmatic Market Validation. Instead of starting with a complex SaaS model, Daniel uses these micro-tools to find “winners” via organic search traffic. By observing where the internet already has unsolved spatial queries, he lets the market dictate which products deserve a full-scale build. In this new landscape, the barrier to entry has shifted: the competitive advantage is no longer “coding ability”—it is strategic experimentation.

4. Not All Traffic is Equal: The High-Value Keyword Insight

One of the most surprising takeaways from this experimentation is the direct link between specific geospatial problems and commercial value. A general GIS data tool might get thousands of views, but a “Roof Area Calculator” generates significantly higher programmatic advertising revenue.

The reason? Market Context. The keyword “roofing” implies high-value intent; a user measuring their roof is likely in the market for a new one, making them incredibly valuable to advertisers. Understanding the commercial landscape surrounding a user’s problem is the difference between a struggling hobby project and a viable MicroSaaS.

5. The Precision Paradox: Why GIS Experts Struggle with UX

There is a fundamental tension between the geospatial technical mindset and the product design mindset. GIS professionals are trained to be exact, precise, and correct. Designers, however, are taught to be wrong, gather feedback, and iterate.

Daniel illustrated this with a “Hot Jar” anecdote. He once built a site where users were failing to move through the revenue funnel. Heat maps revealed the issue wasn’t the data—it was the layout. Users weren’t scrolling down far enough to see the critical action button. The data was perfect, but the UX was broken.

Stella emphasizes that building a product requires the humility to accept that “the best designers of products are the users themselves.” Success often comes from moving a button or simplifying a flow, not from adding another decimal point of precision to the underlying geometry.

6. Launching “Soft” to De-Risk the Rollout

The “perfectionism trap” is the primary reason geospatial products fail to launch. Builders fear that “releasing slop” will damage their brand. However, Stella suggests the Soft Launch (Tool #7) as a vital de-risking mechanism.

A soft launch allows you to:

• Prevent Stagnation: Avoid the “quiet abandonment” of projects that never see the light of day.
• Validate Demand: Ensure people actually want the tool before committing to months of development.
• Build Brand and Trust: In a world where anyone can spin up a tool with AI, trust is the ultimate differentiator.

Launching early ensures continuous improvement and prevents the high-stakes pressure of a single “grand opening” that may miss the mark entirely.

7. Conclusion: The Final Ponderance

Building successful geospatial products is about empathy and process, not just pixels and polygons. Whether you are building a global API or an internal tool for a government agency, the principles of the Swiss Army Knife remain the same.

At the recent Phosphag workshop in Oakland, the range of products—from print maps to digital twins—all shared a common hurdle: the energy to push through the “perfection barrier.”

As you look at your current projects, ask yourself: Am I building this because the data exists, or because a human has a problem I can solve?

Success in the modern landscape requires a diversity of skills—brand, marketing, and distribution. If you aren’t embarrassed by your first version, you’ve already lost the market. Stop building in the dark. Get out there and build the thing.

In Conversation

Stella’s Path to Cartisan: Accidental Cartographer

Daniel: Welcome, Stella. This is going to be a slightly different kind of episode — we’re not focusing on a technology as such, more on what it takes to build one. You gave a workshop at FOSS4G 2025 in Oakland about building products and walking people through the steps involved. I thought a great way in would be for me to tell you about something I’ve made and then you can help us all learn from it.

Stella: That sounds great, Daniel. Maybe we should take one step back first — could you briefly introduce yourself?

Daniel: Of course. Who are you and what do you do?

Stella: My name is Stella Blake Kelly. Originally from New Zealand — as you can probably tell from my accent — but I live in Sydney, Australia, where I founded Cartisan, which is a geospatial product and UX consultancy. We help clients with the front end of their GIS systems: the user interface, user experience, and the overarching product strategy.

Daniel: How did you get there? Do you come from a GIS and cartography background, or was there another path to starting Cartisan?

Stella: It followed my career by falling into things I loved, without much of a plan from the outset. I discovered GIS at Victoria University of Wellington while studying a bachelor of science in geography and environmental studies. We had this amazing guest lecturer with bright blue hair who was so enthusiastic about GIS that I was completely intrigued. I fell in love with it. I always loved Lego as a kid, and GIS scratches that same itch — that constrained creativity involved in building things. After uni I moved to Australia, worked as a geospatial market analyst, then got into product management, and about seven and a half years ago I quit my job to try freelancing. I had three months of savings and wasn’t sure where I’d land — much to my mum’s horror. Fast forward seven and a half years and I’ve got my own business and have worked on so many different projects. Not by planning, but by following the love of GIS.

Daniel: Sounds like so many guests on this podcast — an accidental cartographer. I’m going to ask you later about how much of your own product-thinking framework you applied to starting your business, but let’s save that. First, let me tell you about something I’ve made.

The Roof Area Calculator: A Live Product Critique

Stella: I like to create a supportive environment rather than ripping things to shreds — there’s something to learn in everyone’s work. But let’s go for it.

Daniel: Among many tools I’ve created on mapscaping.com recently — with the help of AI, because I’m not a coder in any shape or form — there’s one I want to introduce you to: a free interactive roof area calculator. It uses an aerial imagery base layer, has a geocoding function so you can search for an address or zoom to your location, and some simple tools to draw and edit polygons. As you draw, it calculates measurements — roof area, pitch, perimeter — and you can export it as a PDF in feet or metres. It’s pretty simple, and it gets a little organic traffic. The approach was SEO-first: I saw people were searching for this, looked at what other websites had, and thought I could make something similar or slightly better. If you scroll down the page you’ll see a lot of text — those words aren’t really for humans, they’re there for search engines to index the page.

Stella: Just to clarify on the vision — I’m assuming it’s not because you want to empower people to know their roofs better. The goal is to generate revenue from ad views?

Daniel: Exactly. Part of how I fund the podcast is through programmatic advertising on mapscaping.com. If I win traffic and generate views, people get shown ads and I generate income to fund the podcast. The interesting thing is this particular page doesn’t get huge traffic, but the traffic it does get has a higher ad value. My guess is it’s because if someone’s calculating their roof dimensions, they might be in the market for a new roof — and advertisers are willing to pay more to be in front of those people.

Stella: Interesting. And how do advertisers know how much to charge for each of those users? Is it cookies tracking behaviour?

Daniel: That’s definitely part of it. And also the keywords the page ranks for. If you go into Google Ads and start typing in keywords you want to rank for, you can see what you’d pay to rank first for that term. Something like “dentist in New York City” might cost $50 to $100 a click. So it’s a combination — cookies telling ad platforms about the user, and the commercial value those platforms assign to specific keywords. That’s actually a great source of evidence for understanding the market context, right?

Stella: Exactly. And good on you for picking up on this. People are so used to googling general things — it makes complete sense that they’re also googling spatial queries. I think the thinking you do for this specific tool will actually help with all your other tools too, because you’re repeating the same process. The context just changes.

Vision and User Needs: Knowing Who You’re Building For

Stella: So, tool number one is Vision. You’re pretty clear on this — it’s about revenue generation. You want to build tools that serve user groups who are also potential customers for high ad spends. Now let’s jump to User Needs — tool number two. This is where you understand your real users and their problems. The challenge is you might know which keywords pay well, but you don’t have much data on who the users actually are or what they’re searching for. What you’ve done is built a proof of concept and captured evidence that people are searching for this. That validates some user need. But what you want to think about more is: who are they, why are they measuring their roof, and is there anything else they’re trying to do as part of that process? Because that opens up more opportunities — for more traffic, or potentially a premium product.

Daniel: That makes total sense. One thing I could do is dive into Google Analytics — it chunks people into user groups and shows where they come from. But I’m not actually talking to anyone. There’s no feedback form, no comments section. I’ve seen other tool websites where users leave really valuable comments, and I have nothing like that.

Stella: Feedback forms are so valuable because they give you direct insight into what users want. When you’re thinking about user needs, you need to understand the real problem the user is trying to solve, the context they’re working in, and build up an evidence base — otherwise you’re working purely from assumptions, and that creates real blind spots. It’s so much easier to make a great product if you have empathy behind your design. And you can’t build empathy without insight into who your users are and what their problems are.

Daniel: With that in mind, what would you suggest I do?

Stella: There are lots of exercises out there — just Google “how do I do user stories.” But a really effective way to step outside yourself is to write some on post-it notes: who the user is, what they’re trying to do, and why. For example: “As a solar panel marketer, I want to find potential customers with enough roof surface area so that I can reach out to them and provide a quote.” By doing that, you’re stepping into someone else’s mindset and thinking about their actual problem. Nobody ever thinks, “I really need to open that GIS tool.” They’re doing it to solve a problem elsewhere. That’s why these exercises are so useful — you step outside the technology mindset and think about who experiences this, what they’re trying to do, and why they struggle.

Market Context and Competitive Research

Daniel: One thing I have been doing — as a way of gathering context — is looking at similar websites offering similar products, seeing what keywords they rank for, and understanding how people arrive there. Sometimes I can find the sites that link to them, go to those pages, and see what problems people are discussing in the comments. It’s not incredibly easy. I’ve also toyed with the idea of getting an AI agent to look at the page and critique it.

Stella: I’ve taken screenshots of tools and sent them to AI for a quick review. It’s not the same quality as a human, but it’s better than nothing. What you’ve just described is actually the Market Context tool — tool number three. You’re looking at the ecosystem your product will fall within: the tools, data, workflows, constraints, what currently exists, and where the gaps and pain points are. That’s where your opportunity sits. And doing this upfront means you’re not discovering overlaps after you’ve already committed all your time. You might find other tools that do the same thing, so you want to make sure you’ve got a point of difference — whether that’s solving a new problem, or just better SEO and a better UI.

Daniel: This research has also helped me think about features — what’s missing in existing tools, what I should be building. But I have a hard time figuring out which feature to build first, where to focus my time.

Stella: That’s a really common problem. You have so many ideas and so many are now possible, and it can be hard to choose. But if you already have a clear vision, understand your user needs, and know the market context, it becomes much easier to apply decision filters and prioritize what should be in your MVP. Your features should be tied to user needs and focused on a very clear minimum viable product. You should be able to park other ideas in a “not now” list. Having this discipline lets you control scope and focus your effort — because this is what turns a weekend project into a month-long one.

Proof of Concept and Scaling to MicroSaaS

Daniel: My strategy — as I mentioned, I’ve made about 200 of these tools — is to make them as quickly as possible, let them sit on the internet for six or eight months, see which ones are winning in terms of organic traffic, which ones people are resonating with, and then filter down to which are generating the most ad revenue, either by sheer volume or because advertisers pay more. Then move forward from there. So let’s pretend I now want to create a mini-SaaS out of the roof calculator. I’ve done basic research, created the tool, and it looks like a winner. What should I be doing?

Stella: I’d recommend going back to some of those earlier tools. The world isn’t ideal — you’ll often find yourself jumping between steps, rethinking your vision after talking to users or doing more market research. For this, I’d start by thinking about what you’ve learned from your first proof of concept: there’s clearly demand for people needing to measure roofs. Then I’d try to flesh out your understanding of who the current users are and what the bigger problem is they’re trying to solve. Once you have that picture, it becomes much easier to think about what other features might be needed, and whether it’s even viable to create a SaaS product off the back of this.

Daniel: When you say viable — do you mean in terms of my time, the resources it’ll take, or the potential income?

Stella: It depends on your success metrics. To me, viability means that all your invested time returns more value than you put in. However much you’re pricing your time, you’re getting enough revenue — ad or subscription — to more than cover that.

Daniel: Would you consider what I have now a prototype, a minimum viable product, or a proof of concept?

Stella: Definitely a proof of concept. A proof of concept is something tangible — a working version of an idea with real representative data and some functionality — but the main thing is it’s been built to learn. That’s exactly what all your tools have been: built so you can learn which makes the most revenue from ads. And this is especially important for geospatial tools because it makes spatial interactions real and actually easier to test with users. It can be incredibly hard to test map interactions with just a diagram. You’ve validated that there’s demand from users for this type of tool, and now it seems like you’re trying to scale up — either growing the number of users, refining it to attract higher ad spend, or adding features that could be upsold to existing users.

Daniel: Yeah, a lot to think about. I can see why we keep coming back to knowing your users — it’s impossible to answer any of those questions without a solid understanding of who these people are and what they want.

Stella: Exactly. You could make a guess — ask AI for five options to change the product and test them. But this is where the value of user feedback forms comes in. That insight translates directly to product value and saves you money because you’re not spending time iterating through things that don’t work. The best designers of products are the users themselves. You’ve already got existing users — you could include a simple feedback form asking what they thought of the site and a bit about who they are. Over time you’ll accumulate enough data to make these decisions much more easily.

UX Blind Spots, Patterns, and the Designer’s Mindset

Daniel: This is a bit of a tangent, but it’s relevant. Mapscaping used to be an e-commerce store, and I fell into exactly the trap you’re describing. We built our website and were incredibly proud of it. But no one was clicking the one button they needed to click to move through the funnel. I installed Hotjar — which makes a heat map of where users move their mouse — and discovered they were simply never scrolling far enough to see the button. We moved it higher on the page, they clicked it, and the whole funnel started working. It was so simple, but I couldn’t see it without that feedback.

Stella: It’s so common. You assume users will use the tool in a certain way and then find they just don’t. It’s a perfect example of how designing without testing creates blind spots — you have inbuilt assumptions like “obviously they’ll just scroll down,” but that’s not necessarily true. A good practice for geospatial product development is to be as scientific as possible: start with a hypothesis, then approach with the intent to validate or reject it. Don’t just assume everything is working. Break it down, check with other people, and iterate. That’s a real agile approach — and it requires working with a lot of humility rather than assuming you’re building the most beautiful thing ever.

Daniel: I definitely have that assumption problem when I’m building interfaces. I only know what I’ve seen before, and it reflects in every interface I build — the flow is always basically the same. I lack imagination. But I also wonder if there’s value in those recognisable patterns for users to follow. Where do you sit on that? How do you know when to break a pattern and when to follow it?

Stella: That’s a real tension point that the geospatial profession often struggles with. We’re trained to be precise and exact. When I contrast that with designers I’ve worked with, they’re taught to showcase their work and get feedback constantly. It’s not about being perfect from the start — it’s an evolving thing you craft by getting other people’s perspectives. That’s very different from how we’re taught to work as geospatial professionals, where you’re expected to deliver the exact thing rather than guide through a process of making. On patterns specifically — it’s the same principle: find something, test it, ask other people if it works. If you’re designing a web application, the GIS professional is probably going to default to: start with a map, add layers, navigate through features. But from a design perspective, you step back and ask what the user problem is, then look at how it’s solved elsewhere outside GIS. You might look at Airbnb or another spatially enabled tool and find interaction patterns that are far more impactful than traditional GIS UI patterns. But again — you’re testing, validating, being willing to be wrong so you can get it right.

Applying the Framework Beyond Tools: APIs, Government, and Launching Well

Daniel: I can see I have a lot of work to do around understanding who’s using this and what they want — that would inform the features I create and whether it’s even worth making. Can you apply this same process elsewhere? Say I’m working in a government organisation and I have a mandate to release data to the world through APIs — is this framework applicable there?

Stella: Absolutely. These foundations apply to anything — data APIs, print maps, anything you’re producing where success is defined by an end person using it. In a government context with APIs, if the vision is purely “this data should be open,” when you release it, you’re ticking that box but you might not find any users. If success is defined as people actually using it, your starting point could be: which is the most frequently requested dataset? Focus there. Then ask: are the users going to know what all the codes and fields mean, or do we need to make them human-readable? Can we assume institutional knowledge? And consider the market context — is another government department already doing this, or is there a private sector equivalent that makes this investment unnecessary? The proof of concept is also incredibly valuable here. I wish it were compulsory for all government tech projects, because it means you’re proving demand before making a huge investment. This all translates to anything being produced — data, tools, or a physical map.

Daniel: That really makes me think about some of my own past work where the KPI was simply “make it open” — and I did, but I didn’t think beyond that. Whether it was used, whether we could have got more value from it — those were open questions I never really asked.

Stella: I’m guilty of not applying these things to my own projects too. It’s always easier from an external perspective. You come in with fresh eyes as a consultant, but when you’re in the thick of it yourself, you fall into rabbit holes all the time.

Daniel: Good. That makes me feel more human. The workshop you held at FOSS4G 2025 in Oakland — were there any trends in what people wanted to build? What kinds of problems were they trying to solve?

Stella: I ran the workshop because I love making things and get a lot of energy from tinkering and hearing about what others are making. We had a huge range — from a print map to a digital twin platform to an internal tool — and everyone was at different stages. Providing a clear, easy framework means you can step back from feeling completely overwhelmed and carve out some tangible, clear tasks to get going. The greatest barrier to products is not anyone’s smarts or discipline. It’s about having the energy to push through barriers and making sure those barriers don’t become insurmountable. It’s about breaking things up, keeping momentum, and not letting perfection get in the way.

Daniel: I totally agree with that. I’ve met so many people working on amazing things who never launch because they’re afraid it’s not perfect. They never talk about it, never market it, never tell their peers. Every time I share one of my tools on LinkedIn, someone shows up to say it’s not good enough or it’s wrong. And part of being a builder is learning to take that, recognise the valuable feedback, and keep moving forward. It’s never going to be perfect — but you’ll never get close unless you launch it and ask for feedback.

Stella: It’s entirely about mindset — having that humility and confidence in the process. You know you won’t be perfect. There are going to be things to fix. That’s just how it works. You don’t wake up one day as an amazing tennis player — you practice, you get things wrong, you win, you lose. Most of the great products out there started as something else entirely. I’ve had so many enterprise projects where enormous effort went into development and then it never got released to the public because people were worried it wasn’t good enough. That’s not conducive to innovation. You need a culture where it’s okay to showcase work that has flaws. The startups we admire have that scrappy nature — “if you’re not embarrassed by your first product, you launched too late.” We admire that from the outside, but when we’re personally on the hook for it, suddenly it’s not so exciting to move fast and experiment.

Daniel: That said, I think you can also launch far too early. Which is probably where the last tool comes in — launch and learn. The launch itself is a tool for learning, and you need to release it in a way that facilitates learning. Maybe a soft beta with a clear feedback loop. That staged approach de-risks the rollout, ensures continuous improvement, and gives the project a more sustainable future. Otherwise you have this pressure to get everything right the first time, no space to adapt, and the product quietly gets abandoned. To be clear — I’m not advocating for creating slop and vomiting it onto the internet. Be thoughtful. There’s a fine balance between being thoughtful and waiting too long. That balance is going to be personal — everyone has to find where it is for themselves. But I know from experience that people sit on things way too long and their dream never gets realised because they never got it out there.

Stella: That’s such an important point. And there’s a real tension between getting it out quickly and putting enough work in so it’s something of substance. With AI tools you can so easily spin up a proof of concept — you’ve got 200 tools on your site — but that has an impact on users when the marketplace is saturated. What then differentiates you is brand and trust. When everyone can make a geospatial product with their AI tool, brand and trust becomes as important — if not more important — than the features themselves.

Daniel: I agree completely, and I’ve been guilty of pushing that a little too far at times and had to wind it back. Brand and trust is undeniably going to become more and more important. I’d add distribution to that as well — it’s one thing to make a product, it’s another thing entirely to get it into the hands of people. Being a trustworthy source is a big part of distribution. But that’s more of a marketing conversation, maybe for another episode.

Stella: And that highlights the importance of GIS stepping outside its industry and learning from others. We’re not going to be brand experts — we’re geospatial experts. So we need diversity in our teams, different skills and experiences, so our products can serve those needs around brand, trust, marketing, and distribution.

Daniel: Could not agree more. Stella, thank you very much. We’ve been using the Swiss Army Knife for geospatial product thinking as a reference point throughout this conversation. Can I link to it in the show notes so people can find it themselves?

Stella: Yes, absolutely. It’s a toolkit that hasn’t had a proper launch yet, so I’d be happy to do a soft launch with the Mapscaping audience. I’d love to get feedback on where people agree, disagree, and how it translates to their own experience with geospatial product development.

Daniel: And then you can dog-food your own tool.

Stella: Exactly. I’ll turn it into an AI plugin —

Daniel: I don’t think you need to do any market research for that. I think you should just rush out and spend six months making it.

Stella: Ha — I was thinking too.

Daniel: Stella, again, thank you very much for your time. I really hope this encourages people listening to get out there and build something, to try something. I think the worst thing that can happen is you’ll learn a new skill. Thank you for giving people a framework to think about what kinds of products might be worth building.

Stella: Thanks for having me, Daniel. And just a note to the audience — which was also the title of my workshop: just get out there and build the thing.