Custom operational workspaces
Bring customer history, reports, quotes, orders and team decisions into a workspace built around the people using it.
Business systems built around how your team actually works.
Starting with the one part of your business that is hardest to run.
I connect workflows, information and AI agents in a focused workspace, with clear permissions and human control where it matters. We can start with one workflow and connect more of the operation as the scope earns it.
Step one
First step: tell me what's getting stuck.
Engagements start by naming the part of the business that is hardest to run. Answer it here and it comes straight to me. It is a conversation, not a commitment.
- You pick the area that hurts and describe it in your own words.
- I read it and reply myself, usually with a question or two.
- If there is a bottleneck worth removing, we talk about that one thing, and I write up a scoped proposal for it.
What we can work on
One workflow first. A more connected operation over time.
Workflow and system integration
Connect supported supplier information to quotes and orders, call history to follow-up, and product records to marketing across your existing tools. Start with one workflow; extend the connections through agreed scope.
Controlled AI-agent operations
Let agents read relevant information and carry out permitted business actions inside your apps, with defined identities, scopes and review boundaries.
Agent participation
Useful actions, with defined authority.
An agent might prepare a quote from supported supplier information, draft a follow-up from customer history, or assemble a listing from product records. The business workflow defines the task; its exception and approval rules define the limits. Its access should match that job: which records it can read, which actions it can take, and when a person decides.
Build a workspace with agent access
Design the staff workflow and agent lanes together, so the same business records support both.
Add controlled access to an existing app
Define a bounded set of reads and actions around a workflow your team already uses.
How the boundaries work
Named agent identities and scoped routes define permitted access. Approval boundaries, assignments and activity records make work reviewable. Some publishing lanes can act under agreed gates; exceptions can require human review. Downstream permissions and a configured action receiver still matter: an available route alone does not establish a working integration.
What gets built
Connected workflows, grounded in real work.
These are the larger end. Most grew out of one problem an owner could name; one is a demo I am building myself, and it says so. A first step is usually much smaller. Customer records and financial figures are redacted, and each case says whether it is in use or a demo.
Flagship proof · Building materials · Nashville
Music City Building Supply
Operating system
A workspace connecting customer, supplier and marketing work.
Explore the ShopBoss workflows- The constraint
- Inbound calls, quotes, supplier pricing and promotions each arrived through their own channel. Whether a customer got followed up depended on somebody remembering.
- What I built
- ShopBoss brings customer history, calls, quotes, orders, supplier-format parsing, product records and marketing tools into a focused workspace for the building-supply business.
- Where it stands
- Austin uses ShopBoss for Music City Building Supply. The screens show connected records and tools, not proof that the whole customer or supplier journey runs unattended.
- Where a person decides
- A person converts each quote into an order and chooses invoice and promotion sends; a live preview and optional test send are available. Supported supplier deals are listed only when they pass price and photo checks; other items are held for review. Current intake coverage needs confirmation.
Express and MongoDB behind a React admin. The API and admin run on a dedicated server; the public storefront is a separate Next.js site and embeddable bundles that read from it.
What it actually removes
- A quote converts into an order with its line items, tax and delivery carried over, and the invoice is produced from that order, so the same items are not re-typed into three documents.
- Calls sync from the phone system onto the matching customer record, and missed calls land in a follow-up queue built from those call records rather than a list someone keeps by hand.
- Promotion emails are built from catalog items and specials already in the system instead of being retyped. Prices are written in when the email is built, so it is worth rebuilding a draft that has sat while prices changed.
- The public storefront reads the same product records the sales floor edits, so there is no second catalog to keep up to date.
Personal training · Lebanon, TN
M.A.R.S.H. Fitness
Live demo · in progress
What a coaching business could run on — my own demo, built for a business that has not adopted it.
- The constraint
- A local trainer's public presence sat on a rented platform that could not feed anything behind it, and the record of each person's assessments and progress lived in notes and memory. I wanted to find out what actually removing that takes.
- What I built
- A public site driven by its own content system, and behind sign-in a coach workspace with scoped coach and client roles: consult pipeline, client records, programs, session calendar and invoicing.
Next.js and Postgres on Vercel, with sign-in, transactional email and a scheduled daily digest.
What it actually removes
- A consult enquiry becomes a client record without re-entry, and the notes taken during it stay attached to that person.
- Programs, the session calendar and invoicing read from the same client record, so scheduling and billing work from one list of who is active.
- The public pages are content rows in the same database, so the site is not a separate thing to maintain.
Interior design
Angela Katherine
Public site + content workspace
An identity change without losing the site she already had.
- The constraint
- An established design practice was changing its name and needed its public presence to move with it — without throwing away the pages search engines already knew.
- What I built
- A rebuilt public site under the new identity, with URL continuity preserved, plus a content workspace where she edits the site's headings, text and images herself.
- Where it stands
- The site reflects the current practice, and routine copy changes no longer need a developer.
Next.js and Postgres on Vercel. Page sections, services and galleries are database rows rather than code, and the old domain redirects path-for-path to the new one.
What it actually removes
- Headings, text and images on each page are edited in place, so a routine copy change needs no developer and no deploy.
- The rename kept its addresses: old URLs redirect to the matching pages under the new identity instead of breaking.
- Enquiries land in the same workspace as the project records they turn into.
Consumer goods · multi-brand
Big John's Nuts
Storefront + shared back office
Separate brands, one shared set of product records.
- The constraint
- Each brand kept its own product, inventory and order records, which meant the same catalog work was repeated brand by brand.
- What I built
- A storefront on its own domain sitting on shared brand, product, inventory, customer and order structures in a common back office.
- Where it stands
- Catalog work happens once and serves each storefront, with room to add the next brand without another platform.
Next.js and MongoDB Atlas on Vercel with product images on S3. Products and orders each carry a brand, and the shared admin is routed on its own hostname, separate from the public storefronts.
What it actually removes
- One catalog, inventory and order surface serves each brand, so adding a brand does not mean standing up another back office.
- Wholesale and retail run off the same product records rather than a duplicated price list.
- Money is stored as whole cents throughout, which avoids the rounding errors that decimal totals can pick up between cart, order and report.
Residential real estate · two brokerages
AmeriKey Realty and John Adams Realty
Publishing workflow
Local knowledge that lived in conversations, published properly.
- The constraint
- What each team knew about individual neighborhoods only surfaced in one-off conversations and scattered posts, so the same research was redone constantly.
- What I built
- Two sites built around sourced, dated neighborhood content, with a research-to-editorial workflow and an explicit review step before anything is published.
- Where it stands
- Local content is reusable and dated, and a person signs off before publication. Brokerage review stays part of the workflow.
Two separate Next.js and Postgres deployments sharing one structure: markdown-backed neighborhood content, plus a research queue that writes candidates and drafts with their evidence attached.
What it actually removes
- Research output is stored as a pending candidate with its sources, not as a published page — publication stays a deliberate human step.
- Neighborhood research is written down once and reused, instead of being redone in each conversation.
- Each brokerage runs on its own deployment and its own database, so each site's material is kept apart from the other's.
How the work runs
Four steps, and a real place to stop.
Each one is small enough to finish and judge on its own. You decide whether there is a next.
- 01
Diagnose one bottleneck
We go through how the business actually runs and agree on the single constraint worth removing first. Before anything gets built, you get a written proposal: the scope, the deliverables, how we will both judge that it is done, and the fee.
- 02
Build the smallest thing that fixes it
Usually that is a workflow or automation built around tools you already pay for — Claude, ChatGPT, your CRM, your back office. Sometimes the problem earns a custom system. We pick the cheaper one that actually works, and anything beyond the agreed scope is proposed separately before it starts.
- 03
Launch it and train the team
It goes live with a person reviewing the steps that need judgement, written documentation, and a walkthrough for the people who will use it. We check it against the acceptance criteria in the proposal, and the handoff happens the way the proposal sets out.
- 04
Ongoing operations, agreed separately
Some systems need hosting, monitoring and adjustments after launch; some do not. Whether there is an ongoing arrangement, and on what terms, is written into the proposal alongside the project rather than bundled into it.
About that fourth step
The project fee pays for the agreed deliverables. Hosting, software licences and any ongoing support are separate from it. Who holds which accounts, what is handed over at the end, and whether I stay involved afterwards are set out in the proposal before work starts, so neither of us is guessing.
Who you are working with
It is me, start to finish.
Austin Adams
Kickfire Creative LLC
I run this as one person with a deliberately small book of work. That is the constraint that makes the rest of it honest.
You talk to the person building it
No account manager, no handoff to a team you have not met. The person who sits with you and works out the constraint is the person who writes the code and hands it over.
The scope stays small enough to finish
One bottleneck at a time, with written deliverables and acceptance criteria for what it means for it to be gone. You pay for those agreed deliverables, and you can judge them when they land.
Nothing important is left to assumption
Before work starts, the proposal sets out the scope, the deliverables, how acceptance works, and how anything extra would be agreed. Ownership, the accounts it runs on, ongoing support and the handoff are written down there too.
A good fit
- An owner or operations sponsor can decide, with a systems or IT counterpart involved where needed.
- The constraint is operational — work that people do every week.
- You want the scope and the handoff agreed in writing first.
Not what I do
- A brochure site with no system behind it.
- A company-wide AI transformation promised up front.
- A pilot with nobody accountable for using it afterwards.
- Unpaid pilots or work on spec.
Before you write
The things owners ask first.
How do we choose the first step?
You tell me where the week goes wrong, and I ask about the parts that sound expensive. We are looking for one thing that costs real time or loses real work, that you could tell had improved, and that is small enough to finish. If nothing meets all three, I will say so rather than invent a project.
Do I need new software?
Often not. The first look is at what you already pay for and whether it is being used properly. New software is worth it when the workflow genuinely does not exist yet — not as a default. Where it runs, and whose accounts it uses, is agreed in the proposal.
What do I pay for?
A project is paid work with a written proposal: the scope, the deliverables, the acceptance criteria and the fee. You pay for those agreed deliverables. Anything beyond them is scoped and agreed separately before it starts. Hosting, licences and ongoing support are separate from the project fee.
Can the first project be a small workflow?
Yes, and that is usually the better place to start. A focused workflow or automation inside your existing tools is cheaper, lands faster, and tells us both whether a bigger build is justified. The systems shown above grew out of that kind of work; they were not the opening move.
What happens after launch?
We check it against the acceptance criteria, and the people using it get documentation and a walkthrough. What happens next — hosting, monitoring, adjustments, or nothing further — follows what the proposal set out. A next improvement is scoped as its own project.
Who owns the work and the data?
Ownership of deliverables, reusable components, hosting accounts, support and the exit or handoff are set out in the proposal before work starts. Client ownership and paid hosting can coexist; the arrangement depends on the scope. Your business data stays yours — I do not reuse it, and anything I would want to show publicly gets your approval first.
The first step
Name the part that is hardest to run.
That is the whole first step. No brief and no discovery deck — just the one thing that keeps costing you the most, and a reply from me.