Rapid Development of Donation Tool for Community Foundation
Pablo Rosero, MSc.
A donation tool for a community foundation, from brief to live demo in 84 minutes
A detailed brief, one AI-orchestrated session and one human approval: what it took to ship a donation and delivery tool, and how it compares with the same project done by hand.
Oct 19, 2026
A case study. Built 18 October 2026 with Claude Code for a community foundation with a children’s library in Bogotá: a public site plus an internal inventory tool. Stack: Vite 8, React 19, Tailwind CSS 4, localStorage. Deployed as a public demo on Vercel.
The requester, who is also the author of this post, pasted a detailed Spanish-language brief into Claude Code: a mobile-first web app for a Colombian foundation that receives in-kind donations and hands them out fairly to families, with 60 sample families in the demo data. It needed a public landing page and an internal tool. The tool had to enforce two business rules: what expires first leaves first (FEFO), and each household gets a monthly points quota by size. It also needed a report showing each donor how many families their donation reached, plus a GitHub repo, a README and a working Vercel URL.
A lead agent wrote and tested the domain core itself, then handed screens to 6 parallel builder agents. It sent the result through an adversarial review of 6 reviewers and 7 fixers, tested the app in a real browser at phone width, and shipped after one human approval. The production URL was live 84 minutes after the brief arrived. Automatic GitHub-to-Vercel deploys were verified at 91 minutes, after the requester asked the agent to retry a link that had failed.
A full by-hand delivery, including discovery, UX design, copy, QA and project management, is estimated at about 440–910 person-hours, or 8–21 weeks for a small agency. That total includes work this session did not do. Coding alone, by one experienced React developer working from a finished design, is estimated at 60–180 hours. Read the gap with care: the session skipped stakeholder discovery, design iteration with the client and usability testing, and it built a demo with no backend. Controlled studies of AI-assisted developers measure far smaller gains, and the section “An existence proof, not an effect size” below explains why the two are not the same measurement.
By the numbers
84 minutes from brief to live production URL; 1 h 31 m to verified auto-deploy (13:12:58 → 14:43:44)
19 sub-agents: 6 builders, 6 reviewers and 7 fixers, plus the lead
87 review findings: 73 fixed, 2 refuted, 8 deferred, 4 merged as duplicates
27 automated tests, with seed data checked on every day of 2026–2027
4 messages from the requester, including one approval to publish
≈ $79 of model compute at Claude Opus 5.5 API list prices
A detailed brief, written as acceptance criteria
In the brief, the foundation receives food, hygiene products, school kits and children’s books from local businesses and neighbors, and hands them out on the second and fourth Saturday of each month. It asked for two things in one Vite + React + Tailwind project with no backend:
A public page with a hero, impact figures consistent with the data, a warm letter to donors and a validated contact form that only simulates sending.
An internal tool with a dashboard, donation intake, stock, families, new delivery and donor report, all mobile-first and wired to real data in
localStorage.It fixed the catalog and points (rice = 2, powdered milk = 4, school kit = 6, books = 1 but outside the quota), the quota tiers (1–2 people = 20 points, 3–4 = 30, 5+ = 40), the seed data (60 families, 15 donors, lots expiring within 15 days and already expired) and the brand: orange #E8842C, green #3F9E6B, dark brown text #2B2216, Nunito and Inter. About twenty minutes in, the requester added the delivery checklist: share the repo with an outside reviewer, keep a working preview URL, and document how to run it, what is simulated and how to reset the demo data.
The brief reads like a scored technical exercise rather than a live client engagement. The foundation’s name, its neighborhood and its library’s name in the app are placeholders chosen during the build, and every family, donor and message in the app is sample data. This post leaves the name out.
The nine acceptance criteria, and how each was met:
Stock shows lots expiring in under 15 days first.
ordenarStock() groups lots by state, then sorts by expiry; the Stock screen keeps that order under every filter. Verified.A delivery takes the soonest-expiring units first.
asignarFEFO() walks lots in expiry order and spills over to the next lot; the delivery screen shows which lot each unit comes from. Verified.No family can exceed its monthly quota.
planificarEntrega() returns a clear error and the Confirm button stays disabled; the save action checks again before writing. Verified.Expired products cannot be delivered. Expired lots are excluded from allocation, locked in Stock, and the product is disabled in the delivery form. Verified.
Quota depends on household size.
cupoMensual(), tested at 1, 2, 3, 4, 5 and 7 members. Verified.Donor report counts families reached.
familiasAlcanzadas() follows deliveries → lot → donor and counts distinct families. Verified.Data survives reloads and closing the tab. Each collection is its own
localStorage key, checked for shape on load and synced across tabs. Verified.Works on a phone, nothing cut off or covered. 16 URLs covering every screen measured at 320 px with no horizontal scroll; the sticky action bar sits above the bottom navigation. Verified.
GitHub repo shared with the reviewer, README, working Vercel URL. Private repo; reviewer invited and has accepted; production URL public; auto-deploy from
main. Verified.Eleven screens, one data model, no backend
The public page uses a hand-built SVG illustration (a house with an orange roof, a book shelf in the window, a small family) in place of stock photos. Its impact figures are read live from the data, so “60 families” and “110 children’s books” always match the tool. The internal tool has a five-item bottom navigation on phones with Deliver raised in the center, and a sidebar on desktop.
Size of the delivered repository (initial commit): 115 files and 12,164 lines added. Of those, about 9,700 lines are source in
src/, 593 are tests, 1,638 are package-lock.json and 153 are the README. Production bundle: 356 kB JavaScript (113 kB gzipped) for the public page, a 155 kB lazily loaded chunk for the internal screens, and 53 kB of CSS.A lead agent, two fan-outs, and a human gate
The session ran from 13:12:58 to 14:43:44 local time. The chart below is drawn to scale from the session log. Each lane is a kind of worker; the bars show when that kind of worker was busy.
Read the brief, plan, check the environment
0 – 9 min · 13:12 → 13:22
The lead agent read the brief and opened a task list the requester could follow. It checked the empty folder, Node 26 and npm 11, the latest package versions, and that the GitHub CLI was signed in. It then spent about six minutes planning before it wrote the first file at 13:22.
Foundation and domain core, written and tested by the lead
9 – 18 min · 13:22 → 13:31 · 48 files, 11 of them placeholders
Scaffold: Vite config, Tailwind v4 theme with the brand palette,
vercel.json with SPA rewrites, .gitignore, fonts and favicon.Business rules as pure functions in
reglas.js: quota, points, FEFO allocation, stock ordering, delivery planning and validation, donor reach.A seed generator that builds 25 lots and runs the real FEFO and quota code to create 41 deliveries across this month and last, so every lot balance adds up.
14 tests, passing on the first run at minute 14. One test regenerates the seed for each of 730 days and checks every invariant.
A shared UI kit (buttons, fields, dialog, badges, quota bar, sticky action bar), the internal layout and navigation, and placeholder pages so the build compiled before any screen existed.
Parallel build: six agents, six sets of files
21 – 37 min · 13:33 → 13:50 · 6 agents · 530 tool calls
Each builder got the same project brief and API reference, plus exclusive ownership of its files: the landing page, dashboard and “More”, stock and intake, families, new delivery and history, and donor report and messages. None could edit the core. Requests for core changes came back in a structured field, and the lead applied two of them right away: a 44 px back link, and a logo that collided with the header link at 320 px. Every builder compiled to its own output folder, and all six also checked their screens in the browser.
Adversarial review, then verify-before-fix
40 – 74 min · 13:52 → 14:27 · 13 agents · 706 tool calls
Six reviewers each examined the app through one lens: business logic, mobile layout, wiring and accessibility, language and content, an end-to-end browser test of criteria 1 to 8, and code quality and delivery. They returned 87 findings with evidence, none severe: 13 medium and 74 low. Findings were grouped by file area and handed to 7 fixers whose first instruction was to try to refute each one. Of the 87, 73 were fixed and 2 refuted with evidence. 8 were deferred because they crossed area boundaries, and the other 4 were duplicates that fixers merged. The 73 also include 4 duplicate pairs that one fixer counted separately, and a few fixes covered only the part inside the fixer’s area. The fixers added 12 tests.
Lead clean-up and hands-on QA
74 – 81 min · 14:27 → 14:33
The most common deferred item was a set of text-search helpers that parallel agents had copied into six files. The lead merged them into one tested module. It then used the app in a real browser at 375 and 320 px:
submitted the contact form;
made a delivery that drew oil from the soonest-expiring lot;
tried to exceed a family’s quota and saw it blocked;
reloaded to confirm persistence;
measured 16 URLs covering every screen for horizontal overflow;
loaded the production build with zero console errors.
This pass found a Spanish agreement bug that all six reviewers missed: “le quedarán 1 punto” should be singular. It was fixed in three places.
One approval, then publish
81 – 86 min · 14:33 → 14:38 · publish took about 1 min
The lead committed locally, then stopped and asked before any public action. After the requester replied “sí” at 14:36:11, it created the private repo, pushed and invited the reviewer. It linked a Vercel project and deployed to production by 14:37:25. While linking, the Vercel CLI, run with
--yes so it would not stop for questions, wrote a token to .env.local and edited .gitignore. The lead noticed, removed the file and reverted the edit before deploying.Connecting GitHub to Vercel
89 – 91 min · 14:42 → 14:43
The first attempt to link the repo to Vercel had failed, and the cause was never confirmed. The lead first blamed Vercel’s access to the private repo, then timing, since the repo was seconds old. When asked to retry, the lead linked it and confirmed the link through the Vercel API. It then pushed a useful README change as a real test and confirmed that Vercel built it from
main and served it at the production URL.What kept quality up at speed
Core first, fan-out second. The rules the brief would be judged on (FEFO, quota, donor reach) were written once, by one agent, and tested before any screen existed. Six builders then coded against a contract that had already passed its tests, instead of six interpretations of the brief.
Seed data made by the real logic. The demo deliveries are produced by the same FEFO and quota functions the app uses. A test checks that on every day of 2026 and 2027 the demo would have a lot about to expire, an expired lot with stock, a family at its full quota, and lot balances that add up.
Dates as local text. All business dates are stored as
YYYY-MM-DD built from local time. toISOString() works in UTC, so in Bogotá it would roll the date forward at 7 p.m. and expire stock five hours early.Exclusive file ownership. Every parallel agent had its own files and folders, so there were no merge conflicts and no agent overwrote another. The cost showed up later as duplicated helpers, which a single clean-up pass fixed.
Review with lenses, fix with skeptics. Six reviewers with different lenses catch different classes of problem. Fixers had to try to disprove each finding before changing code. They refuted 2 of the 87. Nothing checked whether every one of the other fixes was needed.
Contrast decided the button color. White text on the brand orange measures about 2.7:1, which fails WCAG AA. Primary buttons use dark brown text on orange (about 5.8:1), and the green buttons use a darker shade so white text reaches 4.5:1.
A human gate on public actions. Creating the repo, inviting an outside reviewer and deploying were held until the requester said yes. Everything before that point was local and reversible.
Share production, not previews. On this project, Vercel’s default protection puts preview URLs behind a login, while the production domain is public. The README tells reviewers to use the production URL so the link works for them.
What a conventional team would spend
There is no published “hours per screen” benchmark, so the estimate combines two methods and checks them against survey data. The bottom-up method sizes each phase from agency breakdowns [20] [21], writing-pace data [22], a practitioner survey of how effort splits across phases [15], testing-effort bands [23] and per-screen assumptions, which are labeled as assumptions. The top-down method sizes the app at roughly 95–130 function points (an unofficial count). At industry delivery rates of 8–13 hours per function point, that gives an upper bound of 760–1,690 hours [17] [18]. It is an upper bound because those rates include backend work this app does not have.
Phase by phase, the bottom-up estimate by hand against what this build actually did:
Discovery and requirements: 24–48 hours by hand. In this build: no discovery phase, because the brief already contained the rules, catalog and criteria; about 9 minutes of planning, including the environment check.
UX/UI design, including illustration: 64–145 hours by hand. In this build: no separate design phase or designer review. Design lived in code: a token theme, a shared UI kit and an SVG illustration drawn by a builder agent.
Copy in Colombian Spanish: 10–26 hours by hand. In this build: written by agents, then reviewed by a dedicated language reviewer (24 findings).
Front-end build: 248–488 hours by hand. In this build: about 10 minutes of the lead writing the core, plus 17 minutes of six builders working in parallel.
QA, testing and review: 60–130 hours by hand. In this build: 34 minutes of automated review and fixes, about 4 minutes of hands-on browser QA, and 27 tests.
Deployment and README: 6–16 hours by hand. In this build: README written during the build; repo, invite and production deploy in about 1 minute.
Project management: 30–60 hours by hand. In this build: orchestration by the lead agent and one approval from the requester.
Total: 442–913 hours by hand. In this build: 1 h 31 min wall-clock and 4 messages from the requester.
Calendar time. A solo designer-developer working about 30 productive hours a week needs roughly 15–30 weeks. A small agency (designer, one or two front-end developers, part-time QA) running work in parallel needs about 6–15 weeks before client review rounds. Surveys find that 60–80% of projects overrun, with an average effort and cost overrun of 30–40% [19]. Applying that to the schedule stretches it to about 8–21 weeks. In a 2024 survey of web firms, 93% quoted 3–12 weeks for an MVP and 53.7% quoted 16–30 weeks for simple to mid-range web apps [16]. This app is a small custom web app, closer to the second band. This post uses the bottom-up range of 8–21 weeks for an agency, and that may be low.
Coding only. If design and copy were already done, one experienced React developer could plausibly build the app in about 60–180 hours: 15 work units at 4–12 hours each. That is an analyst assumption, not a benchmark. It is well below the 248–488 hours estimated for the front-end build above, which uses agency rates that include handoffs, client revision rounds and more than one developer. It is the fairer comparison for the engineering part alone.
What it would cost
Estimated quotes and published hourly rates are both shown, because they disagree. Quotes for small apps are lower than a full bottom-up count suggests: agencies scope down, reuse templates and skip phases. Published price bands for small business and inventory apps run from about $5k to $50k [27] [28]. Rates are in US dollars. For each option: typical hourly rate, an estimated quote for this scope, and the full bottom-up cost at the central estimate of 600 hours.
Freelancer in Colombia: typical rate $23–41/h [24]. Estimated quote for this scope ≈ $5k–16k (COP 15–50 M). Full bottom-up at the central 600 hours ≈ $18,000 at $30/h.
Colombian or Latin American agency: typical rate $25–99/h [25]. Estimated quote for this scope ≈ $10k–40k. Full bottom-up at the central 600 hours ≈ $30,000 at $50/h. For reference, GoodFirms’ global range is $10k–25k for a simple custom web app and $25k–50k for a complex one [16].
US agency: typical rate $100–149/h [26]. Estimated quote for this scope ≈ $15k–60k, with premium studios up to ≈ $100k, the top of GoodFirms’ global range for custom web apps [16]. Full bottom-up at the central 600 hours ≈ $75,000 at $125/h.
This build: ≈ $79 of model compute [40] plus the requester’s time.
How the compute figure was calculated. The session logs record about 224 million cache-read tokens, 4.6 million cache-write tokens and 0.5 million output tokens across the lead agent and both workflows. At Claude Opus 5.5 list prices ($0.20 per million for cache reads, $5–8 for cache writes and $20 for output), that comes to about $79. Cache reads alone are $45, because every agent re-reads its context on each step. The logs show which cache rate applied: 4.24 million tokens were written at the 5-minute rate ($5 per million) and 0.34 million at the 1-hour rate ($8 per million). This is an API-price equivalent: a subscription plan bills differently, and the research for this case study is not included.
Where it beat common practice, and where it fell short
Review effort. SmartBear’s guidance is to review at under 500 lines an hour, in sessions of no more than 60 minutes [29], based in part on its study of 2,500 reviews at Cisco [41]. At 200–500 lines an hour, one careful human reviewer would need about 19–49 hours for this codebase, and six independent reviewers about 116–291 reviewer-hours. At Google, the median change has one reviewer [30]. Here, six lenses ran in parallel and the fixes landed within 34 minutes. The trade-off: the code arrived as one change of about 12,000 lines, twelve times the 1,000 lines that Google’s public code review guide calls “usually too large” [42].
Review yield. The 87 findings work out to about 9 per thousand lines. SmartBear’s 2006 Cisco study found an average of 32 defects per thousand lines reviewed, in a sample of 300 of its 2,500 reviews [41]. Capers Jones puts the US average defect potential at 5 defects per function point, 1.75 of them in code, which does not convert directly to a per-line rate [33]. A lower count here does not show the code is cleaner. The AI reviewers may simply have missed issues, as the agreement bug that all six missed suggests. 73 of the 87 findings (84%) were fixed. Published rates are not directly comparable, because there a human author decides: in two open-source projects, 65–93% of review suggestions led to a change [31], and developers resolved 73.8% of an industrial LLM reviewer’s comments [32]. Here, AI fixers judged AI findings.
Accessibility and mobile. Touch targets are 44 px. WCAG 2.2 AA requires 24 px [35], 44 px meets the AAA level [44], and Android recommends at least 48 dp [45]. Every screen was checked at 320 px, the width WCAG uses for reflow [36], which is narrower than the 412 px viewport Lighthouse emulates for mobile by default [43]. Text contrast targets AA; in the 2026 WebAIM scan, 83.9% of the top million home pages had low-contrast text [37]. Mobile-first fits the audience: Colombia had 49.6 million mobile internet accesses and 10.5 million fixed connections in early 2026 [39].
Practice by practice, how this build compares with a typical conventional team. Each item is marked ahead, partial, missing or out of scope:
Business rules covered by tests: ahead. In a typical team, test coverage is common but uneven; developers spend about a quarter of their time on tests [34]. This build covers all core rules, plus seed checks on 730 dates.
Multiple review perspectives: partial. A typical team usually has one reviewer per change. This build used six lenses from the same AI model and disputed findings before fixing them, but all six missed the same grammar bug.
Small-screen and target-size checks: ahead. Typical teams often check only at a default device size. This build was checked at 320 px and 375 px, with 44 px touch targets.
Linter, type checking, static analysis: missing. Standard in most teams; none was configured in this build.
Component and end-to-end test automation: missing. Common for apps with flows like this. This build has unit tests only; end-to-end testing was done by an agent in a browser, not as a repeatable suite.
Automated accessibility scan and screen-reader test: missing. This build had manual and code-level checks only. For scale, Deque’s own automated tools caught about 57% of issues by volume in its 2021 study [38].
Usability test with real staff and families: missing. Expected before launch; not done in this build.
Security and data-privacy review: out of scope. Expected for anything holding personal data. Not done here; data stays in one browser, with no accounts.
Re-review after fixes: partial. In a typical team, fixes go through review again. Here, fixes were covered by tests and the lead’s browser pass, not by a second review round.
Friction log
Parallel agents duplicated code. Six files across the app each had their own accent-insensitive search or capitalize helper, with different signatures. That is the price of strict file ownership. A single post-review refactor fixed it.
Shared browser state. Every agent that used the browser shared one browser profile, so test deliveries and lots from one agent showed up in another’s session. Testers had to reset the demo to work from clean data.
A false alarm from hot reload. After live edits, the dev server logged a context error that looked serious. Loading the production build showed it was a hot-reload artifact, with zero errors in production.
A grammar bug six reviewers missed. “Le quedarán 1 punto” (“1 points left”) only shows when exactly one point remains. It took a hands-on test with seed data in that state to see it.
A tool with side effects. The Vercel CLI, run with
--yes so it would not stop for questions, wrote a short-lived token to .env.local and added lines to .gitignore. The CLI said so in its output. The lead checked git status, deleted the file and reverted the edit. The existing .gitignore already excluded .env.local, so the token would not have been committed.A failed link to a brand-new repo. Linking GitHub to Vercel failed seconds after the repo was created and worked six minutes later, after the requester asked for a retry. The cause was not confirmed. The first deploy went out from the CLI, so the URL was live either way.
Architecture changed during review. Fixers added lazy loading of internal screens, an error boundary and stricter storage validation. These were sensible changes, but they arrived without design discussion and without a second review.
An existence proof, not an effect size
Dividing 442–913 by-hand hours by a 1.5-hour session gives a multiplier in the hundreds. No controlled study supports a number like that, and this case study does not claim one.
What controlled studies measure. They measure how much faster a person finishes a task with AI help. Copilot users built an HTTP server 55.8% faster [4]. Field trials with 4,867 developers found about 26% more tasks completed [5]. Experienced open-source maintainers were 19% slower in a 2025 randomized trial while believing they were 20% faster [1]. METR’s 2026 follow-up found some evidence of a speedup, an estimated 4–18% less time per task, with confidence intervals that include zero; METR called that data unreliable and likely an underestimate, because developers who rely most on AI declined to take part [2]. Over 80% of developers in DORA’s 2025 survey believe AI has made them more productive [6], which shows how far felt and measured speed can drift apart. Outside controlled studies, a METR note on 5,305 Claude Code transcripts from 7 of its staff put a soft upper bound of about 1.5–13× on time savings [3].
Why this case looks so different. The work here was not like-for-like. The brief did the discovery work, there was no design iteration with the client and no usability testing, and the app has no backend, accounts or multi-device sync. It is also the kind of task where a controlled study found a large gain, a new and well-specified piece of work [4], rather than the large, familiar codebases where METR found a 19% slowdown [1]. In METR’s January 2026 measurements, the best agent completed, half the time, tasks that take an expert about five hours, with a wide margin of error [14]. A project this size only fits in one sitting when it is split into many small agent tasks with checks between them. Wall-clock time with up to seven agents running at once (19 in all) is also not the same thing as person-hours.
What it costs later. Industry data links AI adoption to lower delivery stability [7] and, in one vendor report, to larger pull requests and longer review times [9]. Other studies report more duplicated code [10] and security gaps in AI-generated code that is functionally correct [11] [12]. Agent-authored pull requests are accepted less often than human ones [13]. Developers say “almost right” AI output is their top frustration [8].
The defensible claim. For a well-specified, front-end-only app on a common stack, one orchestrated session produced a tested and reviewed demo, deployed to a public URL in about an hour and a half. Accessibility was checked in code and in the browser, but not with an automated scan or a screen reader. By hand, coding the same app from a finished design is estimated at 60–180 hours. A full agency project, including discovery and design work this session skipped, is estimated at 440–910 hours. The comparison does not show a production-ready system. That would need a backend, accounts, privacy and security review, testing with the foundation’s staff and families, and someone to maintain it. The fair next step is to log the hours that work takes, and add them to this side of the ledger.
Adding even modest human time narrows the gap quickly. With 8 hours of human review and hardening, the coding-only comparison falls to about 6–19×. With 20 hours, it falls to about 3–8×.
What to repeat next time
A complete brief is the biggest accelerator. Exact rules, catalog, numbers and acceptance criteria replaced weeks of discovery. Vague briefs will not see this speed.
Write and test the domain core before going parallel. Hand builders a tested contract, not the brief.
Give every parallel agent exclusive files. Then plan one clean-up pass for the duplication that causes.
Review through distinct lenses and require evidence. Make fixers try to disprove findings before acting.
Keep a hands-on pass in a real browser. It caught what static review missed. Better still, turn it into a repeatable end-to-end suite.
Gate anything public on a human yes. Check the working tree after every external tool.
Measure from logs, not impressions. Every figure in this post comes from timestamps, git history or tool output.
Add what this build skipped: a linter and type checking, an automated accessibility scan, component and E2E tests, and a usability session with the foundation.
Appendix: measured facts
Each value is followed by its source in parentheses.
Brief received → first command: 13:12:58 → 13:15:40 (Session transcript timestamps)
Core logic tests passing (14 tests): 13:27:22 (Transcript,
npm test output)Build workflow (6 agents): 16 m 46 s · 530 tool calls (Workflow record)
Review workflow (6 reviewers + 7 fixers): 34 m 20 s · 706 tool calls (Workflow record)
Findings by reviewer: code 25 · content 24 · wiring 12 · mobile 10 · E2E 9 · logic 7 (Review journal)
Findings by severity: 0 high · 13 medium · 74 low (Review journal)
Outcomes: 73 fixed · 2 refuted · 8 deferred · 4 merged (Fixer reports)
Lead agent tool calls: 142 (Transcript)
Initial commit: 14:33:38 · 115 files · +12,164 (
git log)Human approval → production live: 14:36:11 → 14:37:25 (Transcript, Vercel deployment record)
Auto-deploy from GitHub verified: 14:43:44 (Vercel API, deployment source “git”)
Tests at delivery: 27 passing (
npm test)URLs checked at 320 px without horizontal scroll (every screen, plus query and not-found variants): 16 of 16 (Browser measurement script)
Sources
Gathered by four research agents with web access on 18 October 2026, then checked again by a separate fact-checking agent that opened every link. Each source was read, not quoted from a search snippet. Agency blogs are marked as lower confidence. Hours and rates come mostly from US, European and global data; Colombian rate data is thinner.
METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, July 2025. metr.org
METR, “We are Changing our Developer Productivity Experiment Design”, Feb 2026. metr.org
METR (A. Deng), “Analyzing coding agent transcripts to upper bound productivity gains from AI agents”, Feb 2026. Exploratory note. metr.org
Peng, Kalliamvakou, Cihon & Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”, 2023. arXiv:2302.06590
Cui, Demirer, Jaffe, Musolff, Peng & Salz, “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”, 2025. Microsoft Research
Google Cloud / DORA, “2025 State of AI-assisted Software Development”, Sep 2025. cloud.google.com
Google Cloud / DORA, “Announcing the 2024 DORA report”, Oct 2024. cloud.google.com
Stack Overflow, 2025 Developer Survey, AI section. survey.stackoverflow.co
Faros AI, “The AI Productivity Paradox Report 2025”, Jul 2025. (Vendor report) faros.ai
GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”, 2025. (Vendor report) gitclear.com
Zhao et al., “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks”, ICML 2026. PMLR
Veracode, “2025 GenAI Code Security Report”, press release, Jul 2025. (Vendor report) veracode.com
Li, Zhang & Hassan, “The Rise of AI Teammates in Software Engineering (SE) 3.0: How Autonomous Coding Agents Are Reshaping Software Engineering”, 2025. arXiv:2507.15003
METR, “Time Horizon 1.1”, Jan 2026. metr.org
Garousi, Coşkunçay, Betin-Can & Demirörs, “A Survey of Software Engineering Practices in Turkey”, J. Systems and Software, 2015 (survey data 2013). arXiv:1412.4648
GoodFirms Website Construction Cost Survey 2024, as summarized by Digital Information World, Jul 2024. (Secondary summary) digitalinformationworld.com
QSM (D. Beckett), “What Does a ‘Typical’ Software Project Look Like?”, 2021. qsm.com
ISBSG, “Resources: Productivity” (project delivery rates). (Rule of thumb) isbsg.org
Moløkken-Østvold & Jørgensen, “A Review of Surveys on Software Effort Estimation”, IEEE ISESE 2003. PDF
Saasfactor, “Mobile App Design Cost: Complete Pricing Guide for 2026”. (Agency blog, low confidence) saasfactor.co
Swiss Tomato, “Website development costs”, Dec 2025. (Agency blog, low confidence) swisstomato.ch
Editorial Freelancers Association, Editorial Rates chart, 2026. the-efa.org
ISBSG (Abran & Jayakumar), “Analysis of ISBSG Data to Understand Testing Effort”, 2013. isbsg.org
Clutch, Top ReactJS Developers in Colombia (directory rates). clutch.co
Clutch, Web Development Pricing Guide, updated Sep 2026. clutch.co
Clutch, Software Development Pricing Guide, updated Sep 2026. clutch.co
Hostinger, “How much does a web app cost in 2026?”. (Vendor blog, low confidence) hostinger.com
SmartBear, “Best Practices for Code Review” (review rate and session length). smartbear.com
Sadowski, Söderberg, Church, Sipko & Bacchelli, “Modern Code Review: A Case Study at Google”, ICSE-SEIP 2018. research.google
Beller, Bacchelli, Zaidman & Juergens, “Modern Code Reviews in Open-Source Projects: Which Problems Do They Fix?”, MSR 2014. TU Delft repository
Cihan et al., “Automated Code Review In Practice”, ICSE-SEIP 2025. arXiv:2412.18531
Capers Jones, “Software Defect Origins and Removal Methods”, 2012. cermacademy.com
Beller, Gousios, Panichella, Proksch, Amann & Zaidman, “Developer Testing in the IDE: Patterns, Beliefs, and Behavior”, TSE 2019. TU Delft
W3C WAI, “Understanding SC 2.5.8 Target Size (Minimum)”, WCAG 2.2. w3.org
W3C WAI, “Understanding SC 1.4.10 Reflow”, WCAG 2.2. w3.org
WebAIM, “The WebAIM Million”, 2026 report. webaim.org
Deque Systems, “Automated testing study identifies 57 percent of digital accessibility issues”, 2021. (Vendor study) deque.com
MinTIC Colombia, ICT bulletin, Q1 2026 (press release). mintic.gov.co
Anthropic, Claude API pricing (Claude Opus 5.5: $4 input, $20 output, $0.20 cache read per million tokens), as listed 6 Oct 2026. platform.claude.com
J. Cohen, “Code Review at Cisco Systems”, in Best Kept Secrets of Peer Code Review, SmartBear, 2006 (2,500 reviews; 32 defects per thousand lines in a 300-review sample). PDF
Google Engineering Practices, “Small CLs”. google.github.io
Google Lighthouse, default mobile emulation (412 × 823 px),
core/config/constants.js. github.comW3C WAI, “Understanding SC 2.5.5 Target Size (Enhanced)”, WCAG 2.2. w3.org
Android Developers, “Make apps more accessible” (touch targets of at least 48 × 48 dp). developer.android.com
Case study written 18 October 2026 from the build session’s transcript, workflow records, git history and Vercel deployment data. The app’s repository is private, and the demo URL is not shared here because it carries the organization’s name. By-hand estimates are ranges built from cited benchmarks plus labeled assumptions, not quotes.
Like this project
Posted Nov 4, 2026
Created a donation tool demo in 84 minutes for a community foundation. A community foundation with a children’s library in Bogotá.
Likes
1
Views
1
Timeline
Oct 27, 2026 - Oct 27, 2026
