Services Work Products About Our approach Insights
Get in touch →

Why we build our own tools, and use them on every project

Dubnium, Cryptex, Paxter, Dingo and Entitle each started as a problem on a real engagement. Here is what each one fixed, and why a small software company bothers to package its own tooling instead of just shipping client work.

The problem with only shipping projects

A software company that only delivers client projects learns the same lessons on every engagement and forgets them in between. The database deployment that went wrong. The connection string that ended up in a repository. The browser tests that were written once and never run again.

Each time, the fix is rebuilt from memory, slightly differently, under deadline. Packaging the fix as a tool means the lesson stays learned, the next client gets it on day one, and our own releases are safer. It also keeps us honest: a tool has to work for people who were not in the room when it was designed.

Dubnium: database change nobody could trace

On long-lived database systems, the question "what has been applied to this environment?" is surprisingly hard to answer. Scripts live in shared folders, deployment steps live in one person's head, and test and production drift apart quietly.

Dubnium fixes that with versioned migration scripts committed beside the code, a tracking table in the target database so a deployment runs only what is pending, schema comparison between environments, variable substitution so one script set serves every environment, and a dry-run mode. It is on NuGet as Booolean.Dubnium.MSSQL, and it runs in the CI/CD pipeline of every Booolean project with a SQL Server database. Read more.

Cryptex: configuration that could not live in Git

Production settings have to be somewhere. Outside the repository, they drift and get lost. Inside it in plain text, they are an incident waiting to happen.

Cryptex encrypts files and folders with AES-256-GCM, takes its passphrase from a prompt, an environment variable or an argument, and understands .enc files well enough to round-trip a whole configuration folder. It is a command-line tool on NuGet, and this website's own production configuration is stored with it. Read more.

Paxter: browser tests that nobody re-ran

Browser tests are the tests most likely to rot. Written once, broken by the next UI change, switched off by the third sprint. Our earlier answer, a Selenium helper library called Bromine, made the tests simpler to write but did nothing about the maintenance.

Paxter moved the test definition out of compiled code entirely. A workflow is a YAML list of actions and data that a tester or analyst can write and review. It runs headless in Chromium, records video when asked, runs workflows in parallel and produces an HTML report. Read more.

Dingo: a schedule that arrived as a spreadsheet

On more than one engagement the delivery plan was an Excel workbook: emailed, copied, edited and handed over through messages, with nobody sure which version was current. Dingo imports the workbook, validates it before anything becomes live work, and manages every item through preparation, production and delivery with full history and a dashboard. It is our delivery management system, and it grew directly out of the matrix planning work we did for a manufacturing plant. Read more.

Entitle: five applications, five logins

As our own family of platforms grew, each one had its own users, its own permissions and its own login screen. Entitle is a centralised authentication and entitlement service: registered applications authenticate against it, users and groups are managed once, and access scopes and actions are answered per application through a client SDK. It is in development on our own platforms first, which is where every one of these tools started. Read more.

What building tools taught us about building systems

  • The problem has to be real. Every tool above came from a specific failure on a specific project. Tools built for imagined problems do not get used.
  • Configuration beats code. Dubnium's dubnium.yml, Cryptex's .cryptex.yaml and Paxter's workflows all put the variable part in a file people can read. It is the same principle we apply to rules engines.
  • Dogfooding is the only honest test. We use these on our own work first. If a tool is annoying, we find out before a client does.
  • Small and sharp wins. Each tool does one job. None of them tries to be a platform.

If any of these would help your delivery, they are yours to try. Dubnium and Cryptex are on NuGet today, and we are happy to talk about Paxter, Dingo and Entitle. Get in touch.

Ready to talk?

What rule, process or platform is holding you back?

Tell us about the system you need to build, fix or modernise. A senior engineer, not a salesperson, will reply.