In one minute

Not every problem needs a platform. Often the highest-leverage software is small and shaped to one job — matched to where the work actually happens.

toolsbrowser-extensionsmobileapps

There’s a reflex, when a team hits friction, to reach for a platform. A dashboard. A system of record. Something big with a login and a roadmap. Sometimes that’s right. But a lot of the time the friction is small and specific, and the fix that would actually help is small and specific too.

We think about this in terms of form factor: where does the work happen, and what shape of software meets it there?

Match the tool to the place

Most work has a natural home. Some of it lives in a browser, inside a web tool your team stares at all day. Some of it happens on a phone or a tablet, in a field, on a site, away from a desk. Some of it happens at the desk but jumps between three apps that don’t talk.

When you notice that, you can stop asking “what platform do we need” and start asking “what’s the smallest thing that removes this friction where it lives.”

  • A browser extension can add a button, an overlay, or a bit of context to a web tool you don’t own. If your team copies the same values between two tabs forty times a day, that’s an extension, not a migration.
  • A single-purpose internal web app can do one job well — a form, a lookup, a converter, a small viewer — without dragging in the weight of a general-purpose system.
  • A focused iOS or iPadOS app meets work that happens away from a desk: capturing data offline and syncing later, running a checklist, or viewing a map or record in the field where a laptop and a signal aren’t guaranteed.

The common thread is that the tool goes to the work instead of asking the work to come to it. A field crew shouldn’t have to remember what they saw and type it into a dashboard back at the office. A person doing the same web task all day shouldn’t have to leave the page to get help with it.

The honest test

A small tool earns its place when an off-the-shelf option can’t be configured to fit, or when fitting it costs more than the friction it removes. That’s the same test we apply to bigger builds: can an existing tool, configured, do this — or am I fighting the tool? If you’re fighting it, a small purpose-built thing is often cheaper to build and far cheaper to live with.

But small doesn’t mean free. This is the part worth being honest about. Every tool you ship is a tool someone has to maintain. Browsers change and extensions break. Operating systems update and apps need to keep pace. A dozen tiny tools with no owner is its own kind of mess — worse, sometimes, than the platform you avoided, because at least the platform had a team.

So the discipline is twofold. Build small when small fits. And keep a real inventory: who owns each tool, what it depends on, and what happens when the thing underneath it moves. A small tool with an owner is leverage. A small tool without one is a future outage.

Where we sit

We tend to reach for the smallest form factor that honestly solves the problem, and we’re happy to say when the answer is a bigger build — or no build at all. Extensions, small internal apps, and mobile and tablet tools are as much a part of how we work as the larger geospatial data and product work we’re known for. If you’re staring at friction that lives in one specific place, that’s usually the conversation worth having. You can see how we think about capabilities, look at the work, or get in touch.

Related work

Stock-picks newsletter

A subscription newsletter with the parts that make it run — email automation and subscriber management — rather than a mailing list bolted onto a blog.

Read the case study →
More insights
All insights