Skip to content
MSP
A single tool icon at the centre with lines spreading outward to several team nodes, one line marked in gold where the first ticket arrived
  • Solution Architecture
  • project-management
  • solution-design
  • geo-tech
  • business-communication

Building the Tool Was the Easy Part: How a Geohash Tool Spread Beyond the GIS Team

Mahardi Setyoso Pratomo6 min readEnglish

A faster internal tool does not spread by itself. How my geohash tool moved from one team to many: pitch at the moment of pain, demo to managers, trim exports.

Read this in Bahasa Indonesia

Why didn't a faster tool spread on its own?

Because speed only matters to people who already know the tool exists and trust it enough to try. I built a self-service tool that turns a polygon into a list of geohashes, and it cut a request that used to take days down to minutes. That result did not move a single team on its own. What moved them was being shown the tool at the exact moment they were stuck, by someone who could answer their questions on the spot.

The technical side of the tool, its design principles and architecture, is in From 2 days to 5 minutes. This post is about what happened after it worked: how it went from my own team to teams that had never asked for it. The tool is open source, and the code is on GitHub.

Where did the tool start?

As a script inside my own team. The Map and Product Ops team handled geohash requests that arrived as tickets through an internal portal, from many different divisions. Each ticket meant a specialist running a script, checking the result and sending a list back.

The script was fast. The queue around it was not. As the number of requesting divisions grew, the bottleneck was clearly people, not compute. So I gave the script a simple web interface and deployed it to the cloud, so anyone with the link could use it without installing anything.

Why did a UI and a cloud deployment matter more than speed?

Because they removed the two things that kept non-specialists out: installing software and reading code. A script, however fast, is a tool for the person who wrote it. A link that opens a map, takes a polygon and returns a list is a tool for anyone.

Screen recording of the live geohash tool: a polygon drawn over a city map turns into geohash cells, and the list is copied as plain textOpen full size
Figure 1. Draw, pick a precision, copy the list: the whole flow on one screen, no install.

My own team adopted it first, and our turnaround on routine requests improved straight away. That was the moment I could have stopped. The tool worked, my team was faster, and the tickets kept coming. But every ticket that still came in was a sign that the teams who needed geohashes most were still waiting on us.

When did other teams actually start using it?

When they had a problem that needed solving that day. Announcements and documentation did little. Adoption happened through a pattern that repeated itself:

  1. A ticket arrives that the requesting team needs urgently.
  2. We get on a video call to clarify the request.
  3. On the call, it becomes clear they would rather not wait for anyone.
  4. I share my screen and show them the tool, using their own area.
  5. They run the next request themselves.
The adoption loop: an urgent ticket leads to a call, the call reveals the team wants autonomy, a live demo on their own area follows, and the team runs the next request themselvesOpen full size
Figure 2. The pitch landed when the pain was live, not when the tool was announced.

The demo worked because it answered the question they already had, with their own polygon on the screen. Nobody needed to imagine a use case.

Why did demos to managers spread it further than demos to users?

Because managers pass a tool on, while individual users mostly keep it to themselves. Beyond the ticket calls, I demonstrated the tool to Tech Operations, Strategy and Planning, and Business Development, and entered it in an internal Product Ops hackathon, where it finished as a top-5 finalist.

The sessions that reached managers had the largest effect. A manager who sees a tool remove a queue for their team does not just use it; they tell their team to use it, and mention it to peers. After a few of those sessions, the tool was being shared by people I had never presented to.

Who saw the demo: an individual requester used it once, a manager spread it to the whole team, and a hackathon audience became aware of it across other teamsOpen full size
Figure 3. One demo to a manager reached a whole team; one demo to a requester reached one person.
Who saw the demo What happened next
An individual requester on a ticket call Used it for their own next request
A team lead or manager Pointed the whole team to it and mentioned it to other teams
A hackathon audience Visibility across teams I did not work with
How the tool spread: from a script in one team, to a cloud tool used by that team, to demos at ticket moments, to managers who forwarded it to several other teamsOpen full size
Figure 4. Each step widened who could use it; managers multiplied it.

What did real usage teach me?

That people use one feature heavily and want the output in the form their next step needs. The tool offered several ways to define an area, but the one used most by far was converting a polygon into geohashes. The other modes still mattered for specific cases, but the main path had to be the fastest.

The bigger lesson was about export. Most geohash lists were going into backend configuration, not into a GIS. Requesters copied the list and pasted it into a config field. So I simplified the exports toward what fit that step: a CSV, or plain text that could be copied and pasted without cleaning.

What I assumed What usage showed What I changed
Users want many input modes equally One mode, polygon to geohash, dominates Kept it the most direct path
Users want GIS formats Most lists go into backend config Prioritised CSV and plain text for copy-paste
What I built versus what was used: several input modes with one dominant path from polygon to geohash, and several export formats narrowed to CSV and plain text for backend configurationOpen full size
Figure 5. Design for the last step: the list ended up pasted into a config field, not opened in a GIS.

What about the people who kept asking the GIS team?

They were few, and I did not try to force them. The ones who kept sending tickets did so mostly out of habit, or because they were genuinely non-technical and preferred to ask a person. For them, the old path stayed open.

Forcing every user onto self-service would have traded a small number of tickets for friction with exactly the people least able to absorb it. The goal was to remove the routine queue, and that happened without them.

What would I repeat for any internal tool?

  • Lower the access barrier before the skill barrier. A link beats an install; a map beats code.
  • Pitch at the moment of pain. A demo during an urgent request does more than any announcement.
  • Demo with the user's own data. Their polygon on the screen answers "will this work for us?" before it is asked.
  • Show managers, not only users. Managers forward tools; users mostly keep them.
  • Watch the last step. Shape the output for where it goes next, here a config field, not a GIS.
  • Keep the old path open. Let the remaining holdouts be a small queue, not a fight.
Six things to repeat for any internal tool: lower the access barrier, pitch at the moment of pain, demo with their data, show managers, watch the last step, keep the old path openOpen full size
Figure 6. The six lessons on one page.

FAQ

How do you get people to adopt an internal tool?

Show it when they need it, with their own data, and make it reachable with a link. Then show it to their managers, who are the ones who pass tools on to whole teams.

Should you force everyone onto a self-service tool?

No. Remove the routine queue and keep a human path for the few who need it. Forcing the last holdouts costs more goodwill than it saves time.

What should you measure after launching an internal tool?

Which features are actually used and where the output goes next. In this case the answer reshaped the exports more than any feature request did.

References

Last updated: 4 November 2026.