What we build — software meant to last years

Software engineering is the main thing we do. Everything else on this site — the insurance intake, the book market, the job board — grew out of it: we built tools we needed ourselves, then found other people needed them too.

Four things we build

1. Custom software

Software shaped around how your organisation actually works, rather than the other way round. Plenty of organisations have spent years bending themselves to fit an off-the-shelf product. Sometimes it is cheaper for the software to bend instead.

2. Web and mobile applications

Fast, scalable, easy to use. Everyone writes those three words, so let us be more specific: a page that opens on a slow connection and an inexpensive phone, and an interface someone can understand without being trained.

3. Civic technology platforms

Platforms that bring governments, organisations and people closer together. This is where our name comes from, and it is the work the team cares most about.

4. Data and analytics

Turning raw data into dashboards and insight that make a decision easier. Data nobody looks at is a maintenance cost, not an asset.

Four things we commit to

This is usually where a company starts making claims. So here is what each one means in practice.

Quality

The code is reviewed, it has tests, and it is meant to run for years — not just on delivery day. Software nobody dares touch six months later has not really been delivered.

Speed

The path from "request submitted" to "written proposal" is short and defined. You are not left waiting for someone to look into it and get back to you. Speed means shortening your wait, not rushing the building.

Accessibility

The site works with a keyboard, works with a screen reader, opens on a weak connection and is usable on a cheap phone. That is an engineering decision rather than a feature we bolted on — and it is implemented on the very site you are reading.

Economic sense

You see a price range before anything starts. And if a piece of work isn't worth the money, we say so early. We have told clients their problem is solved more cheaply by a tool that already exists, and not taken the project.

How it starts

1. Describe what you need on the project request form, attaching documents if you have them.
2. We review it, and ask if anything is unclear.
3. You receive a written proposal: scope, deliverables, assumptions, what is *not* included, a timeline and a price range.
4. Using your tracking code, you open the proposal and accept or decline.

The detail of that path is in how we work.

Previous work

The tools we built for the technical community — the experts club, the book market and the job board — are described in this article.

The projects page shows current and completed work with screenshots and detail. If you want to know who we have worked with, see customers and partners.

Common questions about our software work

Do you take small projects?

Yes. Size is not how we decide. If something falls outside what we are good at, we say so plainly.

Does a quote cost anything?

No. Reviewing your request and writing the proposal is free.

How long until I get a proposal?

It depends on how complex the request is, but the path is defined and you can see where it stands at any time with your tracking code.

Who owns the code?

That is written explicitly into the proposal and the contract, so it is never ambiguous later.

What if we need changes after delivery?

Ongoing support and further development are part of the first conversation and appear in the proposal.