0%

Services · Systems

Software your team actually opens.

Internal tools, AI integrations and niche solutions. The unglamorous half of the studio, built to be used every day instead of demoed once.

Every company has one. The spreadsheet with forty tabs, the inbox that is secretly a database, the process that only works because one person named Kevin remembers how. We replace that with something built for the job, and these days a good part of the job can be handed to an AI that does real work instead of writing poems about it.

What we make

How we build it

  • TypeScript
  • Python
  • Node
  • Cloudflare
  • Claude
  • SQL
  • Your existing stack
  • We sit with the people who will use it before we draw a single screen.
  • AI gets a job description, guardrails and a human fallback. Not a personality.
  • Your data stays yours, in accounts under your name, with access you can switch off.
  • Documented and handed over, so it keeps running when we are not in the room.

How a project runs

  1. Kickoff

    One call. Goals, audience, budget, deadline. You leave it with a plan and a number, because nobody needs a slideshow about our values.

  2. Prototype the hard part

    Whatever scares us most gets built first, in the browser or the engine, on a real mid-range phone. Week one is a cheap place to find out an idea does not work. Week nine is not.

  3. Build in small steps

    You get a build you can click through every week. Break it, complain, send voice notes at midnight. It all goes into the next one.

  4. Polish and launch

    Motion, sound, performance, accessibility. These get real days on the schedule, not whatever survives until Friday afternoon. Then we ship, and we stay reachable after.

Related work

All work

Questions

Also see

Does it have to look as loud as this website?

No. An internal tool should be calm, fast and obvious. It still gets the same care, it just uses its indoor voice.

Which AI do you use?

Whichever fits the job and your privacy rules. Often Claude, sometimes a small model that runs cheaply, sometimes none, because not every problem needs one.

Can it connect to what we already have?

Usually. If it has an API, an export or a database, there is a way in. We check that in week one, before anyone gets attached to the plan.

Who maintains it afterwards?

Your team, with the docs we hand over, or us on a simple support arrangement. You own the code either way.

Got something
worth building?

Rough is fine. Send us the idea before it is tidy, while there is still room to make it stranger.