Neural Trainer
IoT Neuro Cognitive Training Platform
- Ruby on Rails
- Flutter
One software engineer, one designer, and Dap built Crunchloop’s site in five weeks.
Crunchloop used its own platform on its own site: one software engineer and one designer managed Dap operationally to develop and iterate the site across a 5-week delivery window — and shipped it live.
- Plan
- Internal Project
- Team
- Dap + 1 software engineer and 1 designer
- Tech stack
- Dap, Next.js, TypeScript, Tailwind CSS
- Industry
- Technology / Software
- 83.7%of sessions delivered a PR — the rest audited, filed issues only, or were later folded into a rebase
- 69improvement opportunities automatically detected and handled by Dap
- 100%of those 69 opportunities were executed and made eligible to merge — passing checks and ready for review
Story
It was time to update Crunchloop’s website. The previous site did not reflect Dap, the platform now central to how Crunchloop works. This rebuild brings the site up to date: a refreshed design and copy that makes Dap’s capabilities clear and public.
Challenges
Rebuilding your own site with your own platform has a hardness of its own:
- Minimal headcount, real surface area
— twelve routes and the shared foundation underneath them, moving across engineering, content, and design in parallel
- Quality cannot wait
— the checks for design, responsive behavior, translated copy, and search visibility had to keep pace with the build
- Iteration on a live product
— design and implementation needed to move through versions without turning the launch into a big-bang swap
- Everything is on the record
— the repository that ships the site also holds the delivery evidence, including the trade-offs
A small team cannot trade process for speed when the process is the product being demonstrated. The test was whether an agent-operated team could run a governed, multi-track delivery on its own live product — and let the record prove it.
Approach
Crunchloop needed its own site built the way it builds for clients — Dap managed as capacity on the delivery team, not bolted on from outside.
Engagement shape:
- What we committed to
— a build organized around tracked issues, review points, and automated checks on site changes — a governance bar applied to our own front door
- What actually happened
— a short daily sync followed by weekly planning, Dap sessions working against tracked issues, and recurring automations carrying related work while design iterated in parallel
The delivery unit was the point: people, their agent, and a shared process. One software engineer, one designer, and Dap kept multiple tracks moving across the 5-week delivery window, with the record making both the choices and their trade-offs visible.
Results
The loop is the evidence. The site’s output, session records, and delivery artifacts all live in the same place.
1. Delivery flow across a shared repository
PR-level attribution across 237 merged PRs:
- 35.4%84 PRsUnattended Dap PRs — fully Dap-authored, no human intervention
- 64.6%153 PRsAttended Dap PRs — Dap + the Engineer running the sessions
The point: 35.4% of PRs were delivered unattended — substantial features shipped end-to-end, not an AI-suggested snippet. The remaining 64.6% carried direct human guidance from the Engineer operating Dap.
2. We delivered faster and cheaper than Claude Code
Before the build, the team set two delivery estimates: 20 weeks without AI and 9 weeks with Claude Code. It then used Dap end to end and measured the actual delivery against those baselines. Those estimates left out design iteration overhead, which made the real build harder—and Dap’s result stronger.
Dap vs Claude Code
- ~56%Time5 weeks with Dap vs. 9 weeks estimated with Claude Code
- ~37%CostDap token cost vs equivalent Claude API token cost
Dap delivered the site in 5 weeks. Its token spend was approximately $1,300–1,400, compared with an estimated $3,500 for an equivalent Claude API delivery—about 37% of the estimated token cost. Neither comparison includes human hours.
3. Automations carried their share of the flow
Each of these was a recurring family of unattended Dap sessions — triggered on a schedule, not asked for one at a time — that swept the codebase for a specific class of work, opened the issues, and shipped the fixes.
- Component library
— found repeated markup across pages and extracted it into shared, reusable components, so pages compose from a common library instead of duplicating structure
- SEO and search visibility
— tuned how the site is discovered and read by search and generative-engine crawlers: internal discovery paths, crawler-visible trust data, heading structure, and tighter meta descriptions
- Performance audits
— chased performance regressions on the pages themselves: next-gen responsive image formats, lower hero LCP, and trimmed main-thread work
- Design tokens
— replaced hardcoded visual values with named tokens and kept the token system coherent — typography, z-index layers, and baseline alignment
- Translated copy
— kept the locale tree the single source of copy: moved stray labels into it and corrected CTA intent, capitalization, and stale entries
- Responsive screenshots
— caught layout breakage at specific breakpoints across mobile and tablet widths
4. A process, not a one-off build
Our process on top of Dap let us ship a first MVP and iterate to the final version with minimal overhead. That process is now in place for ongoing site maintenance. Seven pages — Home, Why Dap, Use Cases, Features, FAQ, the service center, and Work — each shipped from a versioned design, with documented re-cuts along the way: a restructured mobile hero, a redesigned customer-voice card, higher-density image deliveries, and the removal of a features diagram that no longer earned its place.
With Dap on the team, the constraint was not headcount — it was how much of the loop the team could operate. The loop absorbed flow work while people kept judgment on the path to production.
“The biggest shift was being able to run several tasks in parallel and actually trust it. Each one ran in its own isolated workspace, so they never stepped on each other — I could keep my head on the piece that needed a real decision while Dap took the rest autonomously. It implemented fast and stayed faithful to the design and to what we’d asked for, so my time went into judgment, not into watching it work. And when we wanted to iterate on something or test a concept, we could redesign it — or prototype it directly in code — in a fraction of the time it would have taken otherwise.”
