Technology & Consulting

Technology work, without the theater.

A surprising amount of technology work exists to manage the consequences of earlier technology work. We would rather understand the problem before writing a line of code, then choose the simplest thing that will still hold up in two years.

Common starting points

  • An idea that still lives in a slide deck
  • Tools that refuse to talk to each other
  • A spreadsheet someone updates by hand every Friday
  • A project that has quietly lost its direction

What we work on

Five areas. One question first: what should exist when we’re done?

  • Product strategy

    Most products get built before anyone agrees on the problem. We start there: who it serves, what version one must do and what can wait.

    Typically leaves you withA written product definition and a first-version scope

  • Software integrations

    You already pay for the tools. They should talk to each other without a person acting as the cable.

    Typically leaves you withConnected tools, and a map of how data flows between them

  • Automation & AI workflows

    Repetitive work survives mostly because nobody questions it. We automate it, with AI where it earns its place and plain code where that is enough.

    Typically leaves you withA working automation, documented with its limits

  • Websites & web apps

    Websites, web apps and internal tools, built for their second year and not only for launch day.

    Typically leaves you withA site or tool your team can run and update

  • Technical coordination

    Someone has to translate between what the business needs and what vendors say they deliver. It is a real job. We do it.

    Typically leaves you withShared decisions, a realistic plan and fewer surprises

How a collaboration runs

Four steps, no mystery.

  1. Conversation

    You describe the problem. We ask until we understand it, including whether technology is the answer.

  2. Scope

    What will be done, what won’t, and what it depends on. In writing, before any work starts.

  3. Build

    We do the work, or coordinate the people doing it, with progress you can see.

  4. Handover

    Documentation and access, so running it never depends on us.

Working with Kronoz Labs

Small and independent, by design.

  • A direct line

    You talk to whoever is doing the work. Questions get answers, not ticket numbers.

  • Straight answers early

    If a project isn’t a good fit, you’ll hear it at the start, often with a better route.

  • An actual ending

    Documentation and your own access. A project that only works while we are around is not finished.

Something that should have been fixed years ago?

Tell us what it is and where it stands. A few sentences is enough. The slide deck can wait.

Describe your project