What we do

AI systems your organization owns, built one process at a time.

We set up your Operating Standard in your own accounts, build against real work with the people who do it, and train your team to run what we build. As of fall 2026, our deepest work has been inside West Michigan manufacturers, and the same method applies to non-profits, reps and distributors, and other organizations that run on knowledge work.

Pricing
Scoped per engagement
First conversation
Always free
Ownership
Your accounts and code
Based
West Michigan

Starting points

Good first projects

A good first project is document work that comes around every week, with someone on your team who knows what a right answer looks like. Each of these links to what the system does with that work and where a person approves the result.

The work

What we build

An engagement uses whichever of these the process needs, in the order it needs them, so there’s no fixed package and no menu price. It starts with the Standard and one real process.

01Foundation · In your accounts

Operating Standard and foundation

Everything we build reads from your Operating Standard, so we set it up first. It’s a written, current record of how your organization does its work, kept as plain files that your people and your AI tools both read before they act. In a shop, it’s standard work for your knowledge work. It lives in your company’s own accounts, in private files that keep a history of every change, next to the passwords your company controls.

What it includes

  • Your Operating Standard, with every line naming its source and the date someone last checked it
  • Updates made as part of the work, so when the record and reality disagree, the record is fixed the same day
  • Accounts in your company’s name, with at least two of your own people as owners and our access limited to what the work needs
  • Passwords and keys kept in your password manager, never in documents or AI chats
  • A setup done alongside each employee: their own login, the Standard on their own computer, and a check that it answers from the source and says “not found” instead of guessing
  • Sensitive material kept separate by who is allowed to see it
  • For a process that runs on a schedule, a company-owned machine or cloud account set up with your IT provider, with its own login and only the access it needs

How it usually starts

With the first scoped project. We write down the process we’re about to work on, who owns it, and which systems it touches, and the Standard grows one process at a time from there.

What you keep

  • The Standard, in your company’s accounts
  • Your accounts, owners, and recovery path, written down
  • A second person at your company who can find all of it without us

02Build · With the people who do the work

Implementation, one process at a time

We pick one process that matters, sit with the people who run it, and build against their real work. The best candidates are document work: RFQs, prints and specs in a shop, or grant reports and board packets at a non-profit. The model reads and drafts, code handles the exact math and lookups, and a person approves the result.

What it includes

  • A written process file and a baseline you agree with, so no result gets claimed without a measurement of how the work ran before
  • Exact math, lookups, and comparisons handled by code, with the model reading and drafting around them
  • Review points placed by the people who do the work, kept in place unless an owner decides otherwise in writing
  • Anything unclear sent to a person instead of guessed
  • The new way running next to the old way until the results match and your people accept it
  • A short written update on a regular schedule, reviewed by Holden before you get it: what moved, what’s blocked, and what we need from you

How it usually starts

With a working session at the desks of the people who do the work, or at a whiteboard with the owner and the team. We walk one real job from start to finish, agree on what a better result looks like, and write a scope for that one process.

What you keep

  • The process file, code, instructions, and settings, in your company’s accounts
  • The baseline and the measurement after
  • People who can run it, trace a result to its source, and change it without us

When a process needs more

Tools of its own, and connections to what you run

An app, a report or a connection to another system grows out of an implementation, once the process is written down and someone on your side can maintain what we add.

03Build · The smallest thing that will last

Applications your business owns

Some processes need a tool of their own: an internal app for one team, a report built from the systems you already keep, or a dashboard someone checks each morning. We build the smallest thing that will last, and we confirm that someone on your side can maintain it before we add features. The code, the accounts, and the data are yours.

What it includes

  • The size picked in order: keep the work in a system you already use, then a written procedure, a scheduled job, a small app, and only then something bigger
  • Internal tools, reports, and dashboards that read from the records you already keep
  • Tools your own people already built, moved into company-owned accounts with instructions to rebuild them
  • For anything that runs all the time, a named person on your side who maintains it and a backup who can

How it usually starts

Out of an implementation, when a process needs more than a written procedure or a scheduled job. The first version is small, and it has to earn its place in the working day before it grows.

What you keep

  • Source code and build instructions in your company’s accounts
  • Accounts and data in your company’s name
  • A named maintainer and a written recovery path

04Integration · Your systems stay in charge

Connecting what you already run

Your ERP stays the ERP. We work next to it, reading from approved reports and exports and writing back only where that’s safe and someone has approved it. Email, calendars, shared files, and chat get the same care, so every automated job has its own login and every connection is listed in your Standard.

What it includes

  • Reads from approved reports, views, and exports, with the ERP kept as the system of record
  • Changes written back to the ERP only through paths someone approved and we tested
  • Email, calendar, shared files, and chat connected with an owner’s go-ahead
  • One system in charge of each record, so two tools never overwrite each other
  • Your IT team or outside IT provider involved before we touch your network or admin settings

How it usually starts

Inside an implementation, when a process needs data from somewhere else. We map which system owns each record before anything gets connected.

What you keep

  • A list of every connection, what it can read, and what it can change
  • Logins and keys held in your password manager
  • A written way to switch off any connection

Four parts

What everything we build rests on

The Operating Standard is the base, the written record of how your organization does its work. Skills are repeatable procedures your AI tools follow, kept next to the process they serve and written in plain language any capable AI can run, so you can swap the AI and keep the Standard. Champions are the people on your team who own it. Cadence, if you want it after the handoff, is month-to-month support for measuring, maintaining and improving it.

How the Operating Standard works
The four partsAn exploded assembly drawing of four flat plates stacked on one vertical centerline, each with a numbered balloon. From the bottom: 1 Operating Standard, the sourced, dated record, drawn as the base plate and highlighted; 2 Skills, readable automations; 3 Champions, your people who own it; 4 Cadence, optional ongoing support.EXPLODED VIEW1OPERATING STANDARDSourced, dated record2SKILLSReadable automations3CHAMPIONSYour people who own it4CADENCEOptional ongoing supportTITLETHE FOUR PARTSDWG D-02REV ASHEET 1/1The four partsAn exploded assembly drawing of four flat plates stacked on one vertical centerline, each with a numbered balloon. From the bottom: 1 Operating Standard, the sourced, dated record, drawn as the base plate and highlighted; 2 Skills, readable automations; 3 Champions, your people who own it; 4 Cadence, optional ongoing support.EXPLODED VIEW1OPERATING STANDARD2SKILLS3CHAMPIONS4CADENCETITLETHE FOUR PARTSDWG D-02REV ASHEET 1/1
Drawing D-02The four parts as an exploded view, built up from the Operating Standard.
  1. Operating Standard: your written record of how the work is done, with every line sourced and dated.
  2. Skills: repeatable procedures your AI tools follow, written in plain language.
  3. Champions: the people on your team who own it.
  4. Cadence: optional ongoing support, month to month, for measuring, maintaining and improving it.

After the build

What keeps it working

A system lasts because someone on your team owns it and keeps checking it against what it’s supposed to do.

05People · Inside your company

Team training and Champions

We train your people in your building, on your own work. Champions are the people on your team who own the system after we step back. The handoff test is whether a Champion can add a process and change an automation without calling us.

What it includes

  • Group sessions built on examples from your own work, then time at each person’s desk
  • Ideas from your own people collected and turned into candidate projects
  • Champions trained to run the system, fix it, and change it
  • Written notes from each session for the people who attended

How it usually starts

Alongside the first build, so people learn on a process they already know while it’s being built with them.

What you keep

  • Champions who have passed the handoff test
  • Session notes and materials

06Optional · Month to month

Cadence: ongoing support

Cadence is ongoing support after the handoff, and it’s optional. It’s a month-to-month arrangement for upkeep as models and document formats change. You can cancel any month and everything keeps working, because it all runs in your accounts. The goal is a team that stops needing it.

What it includes

  • Upkeep when a model or a document format changes
  • A regular review of the measurements against the baseline
  • Training for new people and new Champions
  • Troubleshooting, and the next improvements in the order you choose
  • A checkup after a staff change or a long pause that shows exactly where things stand, with nothing restarted or repaired until you approve it

How it usually starts

After handoff, if you want it. It’s never a condition of the build.

What you keep

  • Everything, whether you keep Cadence or cancel it

Ways to start

When the first step isn’t clear yet

An engagement starts with a free conversation. If there’s a real path, the next step is usually a working session with the people who do the job, and that’s typically free too. Then comes a scoped first project, and when the result is uncertain, that first scope is a small paid feasibility test. If you’d rather see the whole picture before choosing a project, an Opportunity Assessment can come first.

How an engagement runs

07A way to start · Half a day to a full day on site

Opportunity Assessment

An option for an owner who wants a full written plan before committing to a first project. We spend half a day to a full day on site with you and the people who do the work, watching real jobs at their desks, and you get a written plan you keep whether we work together afterward or not.

What it includes

  • A sit-down with the owner about what a better year looks like and what should never be automated
  • Time at each person’s desk, walking through the last job they finished
  • A walk through your systems, from the ERP to shared drives, email, and spreadsheets, to see what each one can already export
  • A written plan: how each process runs today, the opportunities ranked by what they’re worth, and a recommended first project
  • An honest list of what isn’t worth automating, and why
  • A walkthrough call on the plan

How it usually starts

With a conversation about whether time on site is the right first step. Often one working session on a single process is enough to scope a first project, and we’ll tell you when that’s the case.

What you keep

  • The written plan
  • A starting copy of your Operating Standard, seeded from the visit

08A way to start · A small paid test

Feasibility first

When we aren’t sure something will work, we test it before you fund a build. The test runs on your real documents and ends with a written decision to go, change course, or stop. If the answer is stop, you’ve paid for the test and nothing more.

What it includes

  • A test on your own documents, including examples your team already knows the answers to
  • The exceptions included on purpose, along with the clean examples
  • A written finding on result quality, the review effort it takes, and the risks that remain
  • A clear decision to go, change course, or stop

How it usually starts

From a working session, when the process is clear and the result is uncertain. The scope names what the test has to show before anything bigger gets built.

What you keep

  • The written finding and the decision
  • Whatever the test produced, in your accounts

Limits

What we’ll talk you out of

We’d rather say these in the first conversation than halfway through a build.

  • A customer-facing chatbot as your first project. Start with work your own people check.
  • Replacing your ERP. It stays the system of record, and we build next to it.
  • Software for work that rarely repeats. A written procedure is often the right size.
  • Anything your people can’t keep running after we leave.
  • A project nobody on your side will own. We ask who the Champion will be before we scope the work.
  • Taking out the step where a person checks the result, unless an owner decides to and writes down why.

Pricing

How pricing works

Every engagement is scoped independently, so there’s no price list on this page. The work differs too much from one organization to the next for a flat number to be fair to either side.

A written scope names the outcomes, what’s left out, how we’ll test that the work is done, and a limit you approve before anything starts. Work stops at that limit unless you approve more. When the result is uncertain, the first scope is a feasibility test instead of a build.

Conversations cost nothing, including the one where we tell you a project isn’t worth doing yet.

Conversations are always free.

Pick the capability closest to your problem and tell us about the process behind it, and we’ll tell you whether this work fits, including when it doesn’t.

Start a conversationHow we work