Status: deployed and currently in beta testing. Try the live site at meetupfinder.com.
Meetup Finder started as a small product idea: remove the friction from a group deciding where to meet. What makes it useful as a portfolio case study is not the application category. It is the development process. I used multiple frontier coding agents as a small engineering organization: one or more agents could propose and implement, while separate agents independently challenged architecture, security assumptions, failure handling, and test coverage.
The first working implementation was produced the same afternoon the initial design was written. The product was then exercised through independent code review, automated tests, real-device validation, and deployment rather than being treated as complete when generated code first ran.
The workflow
- Frame the product and constraints. Define the user problem, privacy boundary, deployment constraints, and explicit non-goals before implementation.
- Write the architecture and implementation plan. Treat the plan as an engineering artifact with risks, exit criteria, and a deliberate order of attack.
- Adversarial design review. Give the design to independent frontier models and ask them to find incorrect assumptions rather than improve the prose.
- Resolve findings before coding. Material findings become design changes, clarified constraints, or architecture decision records instead of being left as review notes.
- Agent-assisted implementation. Use a coding agent to turn the reviewed design into a working system.
- Independent implementation review. Different models inspect and, where useful, execute the result to look for protocol errors, browser lifecycle failures, misleading UI states, security gaps, and missing tests.
- Close the loop with tests and devices. Add regression coverage, exercise the real workflow on phones, and deploy only after the important paths work outside the development environment.
Why independent reviewers mattered
The reviewers did not simply produce stylistic suggestions. They found issues that changed the design and the implementation. Examples included an overstated security property, an incorrect assumption about what infrastructure could observe, browser-storage and page-lifecycle failure cases, ambiguous error handling, and important end-to-end tests that were not yet acting as release gates.
The first architecture used a real-time peer connection. Independent review killed that transport before any implementation of it existed; only the replacement was written.
In one implementation review, an agent wrote an independent compatibility probe rather than trusting the production implementation's own tests. That distinction matters: generated code reviewing itself is weaker evidence than a separately constructed check that reaches the same result.
The human role moved up a level
I did not use the models as autocomplete. My role was closer to architect, technical lead, and release owner: define the product boundary; decide which risks mattered; choose which reviewer findings were valid; reconcile conflicting recommendations; preserve design intent; set acceptance criteria; test the actual user workflow; and decide what shipped.
That is the part of AI-assisted software development I find most interesting. As implementation becomes cheaper, the leverage shifts toward problem selection, architecture, judgment, verification, and the process that keeps several capable agents from confidently converging on the same mistake.
What is intentionally not public
The source repository is private. So are the detailed protocol specification, threat model, implementation plan, architecture decision records, and full adversarial review files. For this product, those documents are not merely commentary around the code; they contain enough resolved engineering decisions to make reconstruction substantially easier with current coding agents.
This case study therefore exposes the engineering process and the deployed result without publishing a build recipe. The live beta is public evidence that the process produced a working artifact; the private design record remains product IP.
What shipped
A small mobile-first web application, deployed to the public Internet and being tested on real devices. The implementation includes automated unit, browser/E2E, artifact, and scenario-harness checks; separate production and test deployment paths; and explicit operational handling for the browser and device behaviors that matter to the workflow.
Live beta: meetupfinder.com · Source and detailed design remain private.
The larger point
The interesting metric here is not lines of code written by a human. It is the amount of validated, deployed software that one experienced engineer can direct when implementation, review, and iteration can happen in parallel through AI agents. Meetup Finder is a compact example: a product idea became a reviewed, tested, deployed beta fast enough that the bottleneck was judgment and validation rather than typing code.
The broader methodology behind this workflow is described in A Discipline for Building Software with AI.
Generated output stats available on request.