Menu
Nederlands

Custom web applications and internal tools

Not every problem fits an off-the-shelf product. I build web applications around the way your team works, from the first version to production, and add AI where it saves time.

Tell me about your project

The problem

A lot of important work runs on spreadsheets, email threads and a patchwork of tools that don't talk to each other. That works until the volume grows, someone is on holiday, or nobody can find the latest version.

Standard software often covers most of the need and forces workarounds for the rest. A focused custom application can be smaller, quicker to use and cheaper to run than you'd expect.

How I approach it

  1. Understand the work

    I start with the people who do the work: what they do every day, where it gets stuck and what the result should be.

  2. A first version quickly

    A small, working version that real people use early on, so we learn what matters before building more.

  3. Built to last

    Proven technology, automated builds and tests, monitoring and backups, so the application keeps running after launch.

  4. Connected to your systems

    Sign-in with your existing accounts, and links to the CRM, accounting software, SharePoint or databases you already use.

  5. AI where it helps

    Language models for reading, summarising and sorting, with checks around them. Not as a gimmick.

What to watch out for

  • Building too much at once. A small first version that people use beats a big plan on paper.
  • Forgetting who maintains it. Agree up front who runs, updates and pays for the application.
  • Copying the spreadsheet. A new tool is a chance to simplify the process, not just to move it.

Projects like this

  • Financial services company
  • 2025

A private AI workspace with many agents

The team wanted AI assistants that don't send data to a public chat app. Now they have a self-hosted chat environment with specialised agents, plus a separate API layer that logs usage and caches answers.

  • A self-hosted chat environment with agents for different tasks.
  • An API layer between the agents and the model providers that logs usage and caches answers.
  • Everything runs on infrastructure the client already had.
  1. Questions and documents from the team
  2. Specialised agents
  3. Layer for logs and cache
  4. Answers inside the client's own environment
  • Software company
  • 2026

A job queue for shared GPU machines

A team of engineers and researchers shared a handful of GPU machines and used a group chat to agree who got which one. Now everyone submits a Docker job to a queue, which starts it on a machine with free resources. A web interface shows the queue, the logs and how busy each GPU is.

  • Jobs are placed by the GPU memory they need, so small jobs can share a GPU and less GPU time goes to waste.
  • Each job runs as the person who submitted it and can only access the folders the rules allow.
  • Users can open a shell in their job. A job can also start a model server for other jobs, which shuts down once those jobs finish.
  • Coding agents can submit jobs and read the results too, through an MCP server.
  1. Docker job from a team memberFree resources on each machine
  2. Select a machine
  3. Run the job as its owner
  4. Logs and GPU use in the web interface

Frequently asked questions

Which technology do you use?

Proven, widely used technology, usually TypeScript or Python with a Postgres database. Where it makes sense, I adapt to what your team already uses.

Can you work with our own developers?

Yes. I can build alongside your team, take on one part of the system, or hand over a finished application with documentation.

How long does a project take?

That depends on the scope. I aim for a first version that people can use within a few weeks, and we plan the next steps from there.