Growing companies outgrow their spreadsheets long before they can justify a systems team. I am that team, on contract: I connect the tools that do not talk, clean the data they disagree on, and build the dashboards and automations that keep a business running on facts. I work mostly with companies under a hundred people. Below is a sample running right now, measured honestly, not the ceiling of what I can build.
The name is a circuit twice over: the timing line down the left clocks your read of this page in three sectors, like a lap, and the data circuits I wire between systems that never met are the work.
| System | Unattended runs | Failed runs | Tests | Status |
|---|---|---|---|---|
| Multi-channel revenue reconciliation | 101 | 0, clean | 456 | RUNNING |
| Warehouse inventory agent | 111, most unattended runs | 0, clean | Not published | RUNNING |
| No-API inventory bridge | Not scheduled | 0 | 329 | SHIPPED |
18,626
rows independently recomputed from scratch and reconciled to the cent
Known limit: Self-reported by a young LLC, not an audited firm. Every figure here is reproducible from a repository you would own, and I will walk any of them with you on the first call.
Book a free 45-minute systems audit (opens the booking page in a new tab)No charge, and you keep the map either way. Prefer email? madison@maddockcircuitsystems.com.
Four things I’ve built so far.
Capabilities · what I build · bound to its limit
Two platforms that both describe the same order, disagreeing on every identifier. I've built the normalisation layer and the idempotent key that makes them agree.
Known limit: When a platform changes how it identifies records, existing mappings break and have to be re-derived. That is a recurring cost, not a one-time setup, and I price it as one.
Pulling records out of systems that were never designed to give them up, including systems with no API at all, and making the result trustworthy enough to run a business on.
Known limit: Cleaning can surface and flag bad source data; it cannot invent data that was never captured. Where a value is missing, the system says so rather than guessing.
Scheduled jobs that reconcile stock across storefronts sharing one warehouse, then compute reorder, deadstock and stockout decisions and route them to whoever acts on them.
Known limit: A daily agent is exactly as fresh as its schedule. Sub-hour decisions need an event-driven design: a different, larger build.
Reporting the operator can correct without a developer. Machine-owned columns and human-owned columns are separated by contract, so an automated run never destroys a manual fix.
Everything here grew out of one company’s problems. That is the starting grid, not the ceiling. The build I want next is the one that looks nothing like these, and I am already looking for it.
These three were built in my operations role at a single multi-brand retail and wholesale group: end-to-end systems work shown in depth, not a wall of logos. The group is described by architecture, not by name; every figure measures my system’s behaviour, never their business.
Reading the colours
Multi-brand retail and wholesale group
Three e-commerce storefronts and two mutually incompatible point-of-sale systems across roughly ten locations. No single view of revenue and, because cost-of-goods was missing or wrong at source, no view of profit at all. Order IDs collided across stores. Manual cost corrections were destroyed on every re-run, so the same reconciliation work restarted from zero each session.
A nightly sync normalising every sale into one schema behind an idempotent line key, with cost resolved through a priority chain and a write contract that updates only volatile fields, so operator-owned columns survive automation.
18,626 rows independently recomputed from scratch and reconciled to the cent across all 18 store-month buckets.
Known limit: A silent 10,000-row platform query ceiling was double-counting records before it was found. Spurious creates ran near 2,000 per run until the chunking strategy was rewritten, and now sit at about 40. The ceiling was the platform's; taking a few weeks to detect it was mine, and the reconciliation audit exists so the next one surfaces in a day.
Four stages, every engagement, in the same order. Each one ends with a document or a working system in your hands, not a promise for later.
| Stage | What happens | What you keep |
|---|---|---|
| 01Systems audit | A 45-minute call, no charge. We walk your systems together and I trace how your data actually moves, and where it stalls. | A written data-flow map, and the three automations in it worth the most to you. Yours to keep, hire me or not. |
| 02Scoped plan | I turn that map into a fixed scope with the price already on it, on the first call, not at the end of a process built to avoid the question. You read it and approve it before any code is written. | A fixed scope and a fixed price, in writing and in your hands before the first commit. |
| 03The build | I write the code in a repository you own, on scoped credentials you create in your own accounts and can switch off yourself. You watch every commit land. None of it runs on my infrastructure. | Working systems in a repository you own, with the tests and commit history that show they do what I said. |
| 04Runbook handoff | I hand over a runbook written while I build, not reconstructed at the end. You keep running the systems yourself, or hand them to any developer you choose. | The runbook, written into the repository you already own. Nothing runs on my machines, so nothing leaves with me. |
Known limit: The stages are the order every engagement runs in, not a promise of what each one finds. A 45-minute audit maps only what 45 minutes can reach, and a scope is an estimate written before the first line of code. When the build turns up something neither of them caught, you see it in the same repository, priced the same way, before I act on it.
Stage 01 ends with a one-page map of how your data moves, and the three automations in it worth the most to you. Here is a whole one, drawn for a business that does not exist, so you can read the deliverable before you book the call. Every figure is illustrative.
Illustrative sampleFictional business, invented figures. Not a real client.
Subject: Northwind Heating and Air, a two-van residential HVAC company, invented for this sample. Any resemblance to a real business is coincidental.
| Source | Movement | Destination | Status |
|---|---|---|---|
| A website booking | Becomes a scheduled job on its own | Scheduling and dispatch | Automatic |
| A scheduled job | Assigned, then pushed to the tech's phone | The tech's mobile app | Automatic |
| A finished job: parts, hours, photos, signature | Retyped into invoicing by hand from the tech's notes, on average four days later; about one job in fifteen is never entered | Invoicing | STALLED, the one place this map flags |
| Parts used on a job | Copied into stock by hand about once a week | Parts stock, vans and shop | Manual |
| A paid invoice | Prompts a maintenance reminder set from memory, or missed | Customer follow-up | Manual |
The three automations worth the most, in priority order, highest value first
The record the app already holds, the parts, the hours, the signature, becomes a sent invoice the same day, with nothing retyped. Four days late turns into same day, and the jobs that slip through unbilled stop slipping.
Illustrative gain, about 5 office hours a week back, and the roughly 1 job in 15 that goes unbilled stops slipping.
Known limit: The app has to capture the job in the field first. A job closed on a paper ticket still will not invoice itself, so this rides on the techs closing every job in the app, and the audit says so before you build it.
The same feed that fixes invoicing already carries the parts each job consumed. Use it to lower van and shop stock and raise a reorder flag before a part runs out, instead of a weekly hand count that is stale the day it is done.
Illustrative gain, the few weekly wrong-part, no-part return trips trend toward zero as stock reflects the vans.
Known limit: Stock stays honest only if what leaves the van is what the app recorded. A part grabbed off a shelf and never logged still drifts. This narrows the gap, it does not close it, and anyone who tells you otherwise is selling you something.
A paid invoice is the signal that a job is finished. Let it schedule the annual maintenance reminder and the follow-up on its own, so repeat revenue stops depending on someone remembering.
Illustrative gain, every completed job books its own next touch, instead of the fraction that get remembered.
Known limit: A reminder is not a booking. This gets the message out on time, reliably. Whether the customer books is still theirs to decide, and no automation should pretend to change that.
Known limit: This whole sheet is a fiction, built to show the shape of the deliverable, not a real client or a promise of numbers. Yours is drawn from your own systems in the 45 minutes we spend together: the stall is wherever your data actually stops, and you keep the sheet whether or not you hire me. Every figure here is invented and marked so. The only real thing on the page is the form.
The person doing the work.
The principal · no handoff, no account manager
Madison Clore. VP of Systems & Operations by day, which is where the production systems on this page were built and where they still run. Maddock Circuit Systems is the vehicle for taking that same work on directly.
Your engagement is separate from that role: it runs on your own systems under scoped credentials you control, and carries no prior-employer code or IP. The systems above are shown by architecture, as proof of capability, not reused.
Durham, NC · Systems integration & data automation
Known limit: I take on a small number of engagements at a time, around the day role above. That means there is sometimes a wait before I can start, and if your timeline cannot move, I am the wrong choice. I would rather tell you that early than take the work and stretch it thin.
The contract, stated plainly.
| Term | Detail |
|---|---|
| Engagement | Fixed-scope builds, or ongoing retained work with a two-week minimum. |
| Systems audit | 45 minutes, no charge. You get a written map of your data flows and the three highest-value automations available to you, whether or not you hire me. |
| Rates | Most first builds start around $2,500; a typical engagement lands between $5,000 and $15,000, with larger phased programs quoted the same way. The exact number comes on the first call, not after a discovery process designed to avoid the question. Fixed-scope work is a fixed price you approve in writing before the first commit. |
| Who does the work | Right now, that is me: no bench, no handoff to a junior, and no account manager between you and the person writing the code. If the firm grows, dealing directly with whoever builds your systems is the standard it keeps. |
| Credentials | Scoped credentials in your own accounts, never mine. You create them, you can see every one of them, and you revoke them without asking me. Nothing runs on personal infrastructure. |
| If I disappear | Everything lives in a repository you own, with a runbook written during the build, not promised at the end. You can hand it to any competent developer. |
A 45-minute systems audit costs nothing and you keep the map either way.
Book a free systems audit (opens the booking page in a new tab)
Prefer email? Write madison@maddockcircuitsystems.com. Replies within 1 to 3 business days.
The questions a careful buyer asks before hiring a small, independent firm. Each answer carries its limit, the same as everything else here.
Small and mid-sized businesses, usually under a hundred people. That is the stage where a company has outgrown spreadsheets and hand-keyed reports but cannot yet justify a full-time systems or data team. If your tools do not talk to each other, your numbers live in three places that disagree, or someone re-exports the same report by hand every week, that is the work. The industry matters far less than the shape of the problem.
Known limit: Both ends of the range are the wrong fit. A company with no core tools chosen yet is better off picking those first, because I connect and automate the systems you already run, I do not choose your CRM for you. A large enterprise with its own data team and procurement is more than a practice this size takes on today. The fit is the stretch in between.
Right now, I do, all of it. There is no bench, no junior the real work is quietly passed to, no offshore team, and no account manager standing between you and the person committing the code. The name on the audit call is the name on the commits, and if the firm grows past me, that is the standard it grows by.
Known limit: Any small firm is a real dependency, and pretending otherwise would be the lie. What answers it here is structural, not a headcount promise: nothing runs on my machines, and the code, tests and runbook all live in a repository you own from the first commit. If I am ever out of the picture, the work is yours to carry on with any competent developer, and none of it is locked to me.
The day role is where the systems on this page were built and where they still run, so it is the source of the capability, not a competitor for your slot. I take a small number of engagements at once and agree your schedule before the first commit, so your build is not the thing that quietly slips.
Known limit: Because I cap how much I run at once, there is sometimes a wait before I can start. If your timeline cannot move, I am the wrong choice, and I would rather say so on the first call than take the work and stretch it thin.
You own it, from the first commit. The repository is created in your account, not mine. Every commit lands in it as I write it, so the code, the tests and the runbook are yours as they are made, not signed over at the end. Nothing runs on my side, so no copy of your system stays with me.
Known limit: What stays mine is the general craft, the patterns and the way I structure a sync, which are the same across every engagement. What is yours is the specific system built for you and everything in your repository. I carry no client's code or data into anyone else's build, and none of yours leaves with me.
Yours, entirely. Systems run in your own accounts on credentials you create and can revoke without asking me. Nothing production lives on my personal infrastructure, and you hold the access, not me.
Known limit: To make data reconcile I do have to read it during the build, so I work against the least access that does the job and you switch that access off the moment we are done. I hold scoped keys while I work, never a standing copy, and the minute you revoke a credential my access to what it opened is gone.
No. Your engagement runs on your own systems under scoped credentials you control and carries no prior-employer code or IP. The systems shown here are proof that the work has been done, described by architecture, never resold to you as new.
Known limit: General skill travels with me between engagements, and that is exactly what you are hiring. What never travels is another party's code, data or credentials, and yours will not travel to the next client either.
You are not stranded. The systems run in your own accounts on credentials you control, the code lives in a repository you own, and a runbook is written into that repository while I build, not reconstructed at the end. Any competent developer can pick it up from there.
Known limit: A runbook shortens the handover, it does not erase it. A new developer still needs time to load the context I carry in my head, and that ramp-up is a real cost. What you are buying is that the cost is bounded and the door is never locked, not that it is zero.
Not yet, and I would rather say so than imply otherwise. Maddock Circuit Systems is a young LLC and I do not carry E&O cover today. What protects you in the meantime is structural, not a policy: the work runs in your own accounts on credentials you can revoke, everything lives in a repository you own, and every build ships with the tests and commit history that show it does what the scope said.
Known limit: Some buyers require a policy on file. If you are one, tell me on the first call and we will work out how to meet it before we sign. What I will not do is claim cover I do not hold.
Case by case, and we settle it on the first call. I will sign a mutual NDA before we get into specifics, and whether we work under your MSA or a short agreement of mine depends on what you bring. I read either one for the same thing first: language that would claim ownership of the repository, the runbook, or my general tools, since the whole model here is that you own the deliverable and I keep my craft.
Known limit: This is a small firm, not a legal department. Heavily negotiated paper adds time before any work starts, and for unusual terms I may have a lawyer review it. I will not sign a clause I cannot honestly keep, or one that contradicts the you-own-the-repository, scoped-credentials model above.
Yes. Every build ships with the tests and commit history that show it does what the scope said, and brittle integrations are built so a break surfaces in CI before it reaches production, not after. On top of that, a 30-day support window comes with the handoff: within those 30 days I fix at no charge anything where the delivered system does not do what the agreed scope said. After that, ongoing support is available on a retainer.
Known limit: A defect is the work not matching the scope it was signed against. A platform changing its own rules, or a new thing you now want the system to do, is not a defect, it is new work, priced as new work, in the same repository, before I touch it. That is the same line the case studies draw.
I show past work by its architecture rather than the client's name, so you can judge whether it transfers to your systems instead of whether you recognise a logo. The work is real and every figure on this site is reproducible from a repository I can walk you through, line by line, on the first call.
Known limit: That does mean you take the specific names on trust until we talk. I would rather protect a past client's confidentiality than trade it for your comfort, because when it is your systems on the table you will want exactly the same discretion.
The booking calendar shows my real availability, so the honest answer is always the one on it. Book the free 45-minute audit at a time that suits you and I will give you a firm start date on the call, once we both know the shape of the work.
Known limit: I take a small number of engagements at a time, so there is sometimes a wait before I can start. If your timeline cannot move and my queue cannot meet it, I am the wrong choice, and I will tell you that on the first call rather than take the work and stretch it thin.
Most first builds start around $2,500, and a typical engagement lands between $5,000 and $15,000; larger, phased programs cost more and are quoted the same way. The exact number comes on the first call, not held back behind a discovery process built to avoid the question. Fixed-scope work is quoted as a fixed price you approve in writing before the first commit, and ongoing retained work runs on a two-week minimum.
Known limit: A fixed price holds for the scope it was written against. When the build turns up something the audit could not reach, you see it in the same repository, priced the same way, before I act on it, never as a surprise line at the end.
Forty-five minutes and nothing else. You get a written map of how your data moves and the three automations in it worth the most to you, and you keep both whether or not you hire me. The catch, if it is one, is that the map is sometimes good enough that people take it and build from it themselves. That is a fair outcome.
Known limit: Forty-five minutes maps only what forty-five minutes can reach. It is a strong first read, not a full audit, and the scope that follows can still surface things the call could not.