Case Study · Our own operation · September 5–12, 2026
What One Owner and AI Tools Accomplished in About 45 Hours
A documented look at software delivery, client work, and marketing at StrAinge Business Solutions during September 5–12, 2026 — with a transparent estimate of comparable conventional effort.
≈45 h
Owner's time
Hunter's retrospective estimate for the period
117
Code changes merged
two software products · not all in production
127
Tracked issues completed
includes planning and tracking work
≈1,000–2,800 h
Modeled conventional effort
internal smaller-task scenario · assumption-based, not measured savings
Jump to — sections marked deep dive hold the method and the evidence
At a glance
- Period
- September 5, 2026, 00:00 to September 12, 14:00 Central — 182 elapsed hours (7 days, 14 hours)
- Owner's time
- Approximately 45 hours of Hunter Strange's work in the period — his retrospective estimate, not a time log
- Starting point
- Both software products and the delivery workflow already existed; this is an incremental delivery period
- Documented output
- 117 merged code changes · 127 tracked issues completed · 4 client and prospect engagements, 22 logged working sessions
- AI's part
- Building, cross-vendor code review, browser testing, research, drafting and editing (Claude Code and Codex GPT-6 Astra)
- Hunter's part
- Direction, specifications, resolving questions, reviewing results, and the business and design decisions
- Modeled comparison
- Roughly 1,000–2,800 conventional professional hours in a smaller-task scenario; 1,904–5,090 in the base model. Internal estimate, not measured
- What this is not
- Not a client story, not measured time saved, not a forecast for any other business
The result
About 45 hours of my time, and a documented record of work
I spent approximately 45 hours working during this period. With AI tools helping build, review, test, research, and draft, we merged 117 software changes and completed 127 tracked issues, while client delivery and marketing work kept moving.
Going in, I guessed that doing the same work without AI would take around 350–500 professional hours. When we modeled it, even a scenario using substantially smaller estimates of task size came back at roughly 1,000–2,800 hours.
That is an internal estimate, not measured time saved. We don't have a conventional team's timesheets for the same work, and the assumptions materially affect the result. My own 45 hours is a retrospective estimate, too.
But the output is documented. For me, this was an overwhelmingly positive demonstration of the capacity these tools can give a small business.
— Hunter Strange, founder
Reading the numbers
- A merged code change is one reviewed, self-contained change accepted into a product's main codebase — a feature, a fix, or a follow-up. Merged does not always mean released: some were running in a test (staging) environment when the period ended.
- A tracked issue is one item of work in our task tracker. Completed issues include planning and tracking items, and they overlap the work behind the merges, so the two counts are different views of related work, not separate deliverables to add together.
- The 45 hours is Hunter's own working time in the period — not elapsed calendar time, not how long the AI tools ran, and not the effort to build either product. Both products and the delivery workflow already existed; this was an incremental delivery period built on those foundations.
- The period runs from September 5, 00:00 to September 12, 2:00 p.m. Central — 182 elapsed hours, or 7 days and 14 hours.
What moved forward
Software, client work, and marketing in the same week
Selected examples, described without identifying details. Each carries the state the records support at the end of the period: in production, on staging, prepared, submitted, scheduled, published, signed, or completed.
Our own business platform
45 merged changes, each followed by a production deploy. Our platform is described in the Palanae case study.
- A spend-request flow in two sizes: phone-first approvals, an account-mapping wizard and a finance exportProduction
- One email and password across the product and its client portal, including the database change behind itProduction
- A same-day fix for portal requests that hung, traced to how the app shared database connectionsProduction
- Layout and usability repairs found by browser-based visual review on phones, tablets and desktops, in both color themesProduction
- An imported travel date without a cited source now waits as a proposal for a person to confirm or keepProduction
A client's community-marketplace platform, built under contract
72 merged changes. One production release early in the period covered some of them; most were deployed to staging by period end, and production promotion is the client's decision.
- A compliance-document engine: requirement library, document binder with secure uploads, and an applicant checklistStaging
- Sign-in options on the account page: add or replace a phone number or email, and ask before creating a new accountStaging
- A market-day check-in dashboard with its own gate roleStaging
- A public page for each vendor, with a primary category and an assigned linkStaging
- Sign-in consent screens and related cloud configuration applied across development, staging and productionProduction
Client and prospect work
Four client and prospect engagements, with 22 logged working sessions. Prepared work was not necessarily delivered or accepted by the end of the period.
| Engagement | Work | State |
|---|---|---|
| A charter operator building a media program | An eight-page fillable intake questionnaire, a verified onboard-video equipment blueprint, and a parts list sorted into purchase groups | Prepared |
| The service agreement | Signed | |
| A pool-service company | Customer records moved from a legacy export into a field-operations app: 140 imported, 183 total customers verified afterward (43 were already there). The imported records were still leads at verification | Completed |
| A construction-technology prospect | Consultation notes organized and a nine-item research plan written | Prepared |
| A community-marketplace startup | App-store organization enrollment | Submitted |
| Payments account activation | Completed |
Our own marketing
- Company positioning and messaging updated across the working documentationCompleted
- Brand social cards rebuilt, each checked for contrast, text overflow and fontsPrepared
- A short video edited into three localized versions with corrected captionsPrepared
- A social scheduling platform connected; three Instagram posts scheduled and confirmed in the schedulerScheduled
- A Facebook postPublished
How the work happened
AI did the building and checking. Hunter set direction and made the calls.
What AI did. Coding agents from two vendors — Claude Code and Codex (GPT-6 Astra) — built and reviewed the software, with the reviewer always from a different vendor than the builder. An AI agent tested screens in a real browser. The same tools researched, drafted and edited client documents and marketing, and prepared the customer-data import.
What Hunter did. He defined the work and its acceptance criteria, resolved the questions the tools raised, reviewed results, decided what counted as a defect, and made the business and design decisions. He did not personally merge or deploy every change: approved changes merged under standing rules he set, with exceptions coming back to him, and automation handled much of the release path.
- 1
Define
Hunter
Decides what gets built and why; each issue gets written acceptance criteria, drafted with AI help and approved by Hunter
- 2
Build
One vendor's AI agent
Picks up the issue, writes the code and tests, and opens a change for review
- 3
Review
A different vendor's AI agent
Checks the change against the issue and the required automated checks; the reviewer is never the same vendor as the builder
- 4
Merge
Standing rules
Approved changes merge under rules Hunter set; questions and exceptions come back to him
- 5
Release
Varies by product
Our platform: Hunter runs production deploys. Client platform: a pipeline deploys to staging; production promotion is the client's call
- 6
Verify
AI agent in a real browser
Checks screens on phone, tablet and desktop in both themes and files repairs; Hunter decides what counts as a defect
The tools do the work. The person decides what gets built, what ships, and what the tools are not allowed to do.
The estimated comparison
What comparable work might require without AI
Modeled conventional effort · smaller-task scenario
≈1,000–2,800 hours
An internal estimate, not measured time saved. No conventional team did and timed this work, most of the model's inputs rest on weak benchmarks or judgment, and changing its assumptions changes the result. The owner's 45 hours is also a retrospective estimate.
We built an internal model of how many hours competent professionals, working without AI assistance, might need for the documented work in this period. Its base version returns 1,904–5,090 hours. The figure we feature comes from a scenario that deliberately shrinks the model's largest driver: every code build and repair moved down one size tier, with coordination recalculated. That returns 982–2,765 hours, which we round to roughly 1,000–2,800.
The smaller scenario is not a proven minimum or a confidence interval, and no independent reviewer has validated it. It is simply the less generous of the two versions. Its absolute accuracy is unknown.
The model covers the work in our register — the 117 merged changes and their review, repair and release; visual review; specification sessions; the 22 client and prospect sessions; and the social assets — plus a coordination allowance. It is not a valuation of everything mentioned on this page. Nor does it produce hours saved, a productivity multiple, or a cost comparison, and we don't derive any of those from it.
| Scenario | Modeled hours | What changes |
|---|---|---|
| Smaller task sizes (featured) | 982–2,765 h | Every source- and test-code build and every repair shifted down one size tier; publicly rounded to roughly 1,000–2,800 hours |
| Base model | 1,904–5,090 h | Task sizes as classified from the size of each change and the activity records |
| Larger task sizes | 3,426–8,948 h | The same one-tier shift upward, shown to make the sensitivity visible in both directions |
How the model works, its limits, and its largest lines are in the methodology section.
Why it matters to a business owner
The work that keeps waiting behind the daily operation
Every business has a list that never gets shorter: the customer follow-up that slips, the information typed into two systems, the tool your team needs but nobody has had time to build, the project that moves to next week again. That work doesn't wait because it doesn't matter. It waits because everyone is busy running the business.
What this period showed us is how much of that kind of work one person can move forward by directing AI tools with clear rules: work written down before it starts, a reviewer that isn't the builder, a person deciding what ships, and a record of what happened.
Your results will depend on your business and the work involved, and nothing here is a forecast for another company. But if one bottleneck keeps getting pushed to next week, that's a good place to start a conversation. Our AI services page shows how we help identify that work, design the solution, and put it into use.
Methodology
How the conventional-effort model works, and what it cannot establish
How it was built
- We first reconciled every merge, completed issue and created issue in the period into one internal register, checked against the code hosts and issue trackers, including a random spot-check of ten records against their sources.
- Each activity in the register was given a low and high hour range for a competent, mid-level professional working without AI assistance. Ranges came from the size of each code change, the activity records, generic published benchmark references, and estimator judgment.
- Code changes were sized by hand-written lines, with source code and test code sized separately. Generated files (about 38,700 lines) were excluded.
- Review was sized from reviewable lines per round. Changes with a recorded review history used it; the 72 changes without one were assumed to need a single round (46–99 hours).
- Coordination was added as a single allowance of 10–20% of direct software work (168–821 hours in the base model), not as a modeled team structure.
- The estimate was produced by an AI model working from the register, separately from the earlier draft figure. That separation is not independent human validation.
What it cannot establish
- There is no matched human record. No conventional team built and timed this work, so the model cannot be checked against actual hours.
- Most of it rests on weak support. In the base model, 94% of the low figure and 95% of the high figure rest on weak benchmarks or estimator judgment. Code review was the only input with moderate published support; specification, migration, infrastructure and advisory work had no directly comparable benchmark in our review. External references give context; they do not measure this work.
- Task-size classification drives the result. Shifting the build and repair size tiers one step moves the total by roughly half to three-quarters in either direction, as the scenario table shows.
- AI-built work may not match what people would write. Test code added (about 30,800 lines) exceeded source code added (about 21,700). A human team might have written less, and in larger batches, so sizing by lines may credit volume a conventional team would not have produced.
- Some effort covers earlier work. 46–108 hours of the visual-review line was spent during the period checking work shipped before it.
- The owner's hours were not logged. The 45 hours is a retrospective estimate. Dividing modeled hours by it would produce a modeled ratio, not an observed productivity result, so we don't.
A later update could be strengthened by logging owner time as the work happens, or by having an independent human estimator size a sample of the same work packages and comparing the results.
Largest lines in the base model
| Activity | Base hours | Scope |
|---|---|---|
| Building the 117 merged changes (source and test code sized separately) | 1,436–3,493 | 117 changes |
| Coordination allowance, 10–20% of direct software work | 168–821 | one judgment line |
| Code review | 113–246 | 45 changes with evidenced rounds; 72 assumed at one round (46–99 h) |
| Browser-based visual review | 61–143 | 46–108 h of it on work shipped before the period |
| Client and prospect working sessions | 45–128 | 22 sessions |
| Repair after changes were requested | 23–72 | 13 sent-back cycles |
| Specification sessions | 18–60 | 6 held sessions |
| Social assets | 12–38 | 37 assets |
| Database migrations: authoring and applying | 14–45 | 12 migrations |
| Deploys, infrastructure and incident diagnosis | 14–45 | deploys, cloud configuration, one incident |
| Total, base model | 1,904–5,090 | no point estimate |
Rows are rounded ranges from the model and do not sum exactly to the total. The smaller-task scenario changes only the build and repair lines and the coordination allowance that depends on them.
Evidence appendix
The output record, redacted for publication
Counts come from our code hosts, issue trackers, engagement session ledgers and scheduler read-backs for the stated period, reconciled into an internal register. The raw register contains internal titles, client records and authenticated links, so it is not published.
| Measure | Count | Definition and limits |
|---|---|---|
| Merged code changes | 117 | 45 on our own platform + 72 on the client platform. A merge is not necessarily a production release |
| Tracked issues completed | 127 | 49 + 78. Includes planning, tracking and scope-stub closures; overlaps the work behind the merges |
| Tracked issues created | 134 | 131 excluding three duplicates. Creating an issue does not mean it was ready to build |
| Database migrations first committed | 12 | 2 on our platform (applied to production) · 10 on the client platform (8 with staging-apply evidence; none promoted to production in the period) |
| Visual checks with a recorded result | 306 | 233 passed · 48 failed · 25 blocked (could not be completed). Distinct checks; repeat observations excluded. Most of our platform's checks covered work shipped before the period |
| Code review evidence | 58 rounds | on 45 merged changes, with 13 sent back for changes; the other 72 changes have no recorded round count |
| Client and prospect engagements | 4 / 22 | engagements / logged working sessions. One is a prospect. Sessions are not deliverables or measured hours |
| Hand-written code changed | +21.7k / −3.3k | source lines added / removed; tests +30.8k / −0.9k. 38.7k generated lines excluded |
Merged changes by day (Central time)
| Day | Our platform | Client platform |
|---|---|---|
| Sep 5 | 4 | 0 |
| Sep 6 | 0 | 9 |
| Sep 7 | 6 | 15 |
| Sep 8 | 7 | 9 |
| Sep 9 | 8 | 7 |
| Sep 10 | 11 | 15 |
| Sep 11 | 9 | 13 |
| Sep 12 (to 2 p.m.) | 0 | 4 |
| Total | 45 | 72 |
What this page does and does not claim
- The period is September 5, 2026, 00:00 to September 12, 2:00 p.m. Central: 182 elapsed hours.
- The owner's approximately 45 hours is a retrospective estimate of his own work in the period, not a time log.
- The conventional-effort figures come from an internal model. They are not measured hours, hours saved, a productivity multiple, a cost or return figure, or a claim about how long any particular team would take.
- Merged changes are not all production releases. Completed issues include planning and tracking work. Prepared client work is not necessarily delivered or accepted.
- Client work is described without identifying details. Nothing here is a claim about any client's results.
- This describes one firm's period of work on existing products. It is not a forecast or guarantee for any other business.
What keeps getting pushed to next week?
Tell us about one bottleneck in your business. We'll talk through whether and how these tools could help move it.
Start the Conversation