Key Takeaways
- Pure, I/O-free modules made Huddle Up safe for coding agents to iterate on.
- ADLC governs the loop: write, test, self-correct, then a human reviews.
- Guests answer with no account; organisers sign in with no password.
- A database transaction, not application code, prevents overselling a seat.
- Huddle Up is now part of Bitcot’s accelerator library.
Introduction
Agreeing on a meeting time with a group still eats a week. Someone proposes three options in a thread. Two people reply. One answers at midnight from a different time zone. Another responds about the wrong week entirely. The organiser ends up acting as a human spreadsheet, chasing replies and converting time zones by hand, while the people being asked are handed a link and told to make an account before they can say “Tuesday works.” Most of them never will.
Huddle Up was built to close that gap: a real-time, no-account scheduling tool that turns “let’s find a time” into one link and a settled answer. What makes it relevant to this blog is not the scheduling problem, which is well understood. It is how most of it got built.
We ran coding agents in a governed agentic loop under our ADLC, Agentic Development Lifecycle, process to write and test the majority of Huddle Up’s hardest logic. That was only possible because of one architectural decision made before any agent touched the code: isolating the riskiest logic into small, pure modules with no database, browser, or network calls inside them. This post covers both halves of that story, the product and the process that built it, because they are the same decision seen from two directions.
What Is Huddle Up?
Huddle Up is a scheduling platform with three purpose-built shapes instead of one generic grid forced to serve three different questions. A group poll answers “which of these times suits everyone.” A sign-up sheet answers “pick one of these sessions; there are only six seats.” A booking page answers “book any free half-hour in my week.”
The organiser is the only person with an account, and even that account has no password: a one-time code emailed on sign-in creates it automatically on first use. A guest never creates an account at all. They open a signed, opaque link, answer in their own automatically detected time zone, and give a name and email only after answering, not before. That ordering- answer first, identify second- is the single decision responsible for most of the response rate difference between Huddle Up and a tool that gates the question behind a sign-up form.
What Is an Agentic Loop in Software Development?
An agentic loop is the repeated cycle a coding agent runs on its own: write a change, run it against a test, read the result, and revise, without a human approving each individual step in between. The loop only terminates, successfully or by escalating to a person, when the code passes its tests or the agent exhausts a defined number of attempts.
That definition explains why the loop is powerful and why it is also risky without structure. An agent iterating against a fast, deterministic test gets a clear signal within seconds and converges quickly. An agent operating against a live database, a real email send, or a browser session gets a slow, sometimes nondeterministic signal, and a bad iteration can leave side effects, a sent email, a written row, that a retry does not undo.
What Is ADLC?
ADLC, the Agentic Development Lifecycle, is the governance layer Bitcot runs around that loop as part of our broader approach to AI agent development. It defines which parts of a codebase an agent is allowed to iterate on unsupervised, what test suite gates a change before it can be considered passing, what gets logged for audit, and where a human review gate sits before anything reaches a system with real data or real users. ADLC is not a tool. It is the set of boundaries that make an agentic loop something you can run in a professional engineering process rather than an experiment you supervise line by line.
Huddle Up is a working example of those boundaries in practice, and the rest of this post is about where we drew them.
Why Huddle Up’s Architecture Is Built for Coding Agents
Rather than a layered MVC or MVVM pattern, Huddle Up concentrates its hardest logic into five small, pure deep modules: code that can be fully tested without a browser, a database, or a network connection. Each module takes plain data in and returns plain data out. Route handlers and server actions call these modules after loading real data, and write the result back.
That constraint, no I/O inside the module, is precisely what makes a module a safe candidate for an agentic loop. A coding agent working inside one of these modules gets an answer in milliseconds from a local test run, with no database state to reset and no network call to mock. A wrong answer surfaces immediately as a failing assertion, not as a support ticket three weeks later.
The five modules:
- Availability Engine. Given a weekly pattern of open hours, a meeting length, a buffer, a notice period, and a set of busy intervals, it returns exactly which times are bookable.
- Time Zone Service. Owns every conversion, DST-safe calculation, and formatting decision. No feature code touches a date library directly.
- Poll Tally. Given a set of votes, it ranks candidate slots and names the winner and the reason.
- Capacity Ledger. Owns claims, seat counts, the one-seat-per-person rule, and waitlist promotion.
- Guest Identity. Issues and verifies the signed tokens that let an account-less guest own their own answer, using the same token-based pattern that underlies identity and access management work more broadly.
How the ADLC Loop Actually Ran on This Build
Each of the five modules already had a specification: the plain-language description above is close to what a module’s test file actually asserts. A coding agent working on the Capacity Ledger, for example, was scoped to that module alone, with its existing test suite as the pass condition. The agent wrote or modified the module, ran the suite locally, read any failing assertion, and revised, repeating until the suite passed or a retry limit was reached.
Nothing in that loop touched a live database or sent a real notification. The one-seat-per-person rule and waitlist promotion logic were exercised entirely against synthetic data inside the test file, which is what let the loop run unsupervised through dozens of iterations without a human confirming each one.
The human review gate sat one level up, at the point where a module’s output gets wired into a real route handler that touches the actual Agentic Development Lifecycle boundary between agent-authored logic and production data. That wiring step, and anything involving the real database schema, authentication, or outbound email, was reviewed by an engineer before merge. The agent proposed the logic. A person approved where it was allowed to run.
The Product Itself: Three Shapes, One Underlying Engine
A group poll places candidate times on a calendar, greys out slots that conflict with an existing calendar event, and lets each guest mark yes, if-need-be, or no against every option. Every submitted answer updates a shared grid in real time, the strongest column is highlighted automatically, and the organiser confirms it in one click. The Poll Tally module is what ranks the columns and names the winner; the interface only renders what that module already decided.
A sign-up sheet publishes multiple sessions, each with its own date, time, and seat count, and restricts a guest to one seat at a time across the whole sheet. An optional waiting list promotes automatically when a seat frees up. Claiming a seat and joining the waiting list both run inside one serialized database transaction locked on the session itself, so two people racing for the last seat cannot both win it. That guarantee comes from Postgres, not from application code checking a count before inserting a row, which is the difference between a guarantee and a race condition that happens to work most of the time.
A booking page lets a visitor book any free half-hour in the organiser’s week, with a configurable meeting length, buffer, and notice period, and open hours that can be overridden for a specific date. The same Availability Engine that renders the public booking page also produces the organiser’s own “slots per week” preview while they configure it, so what they see while setting hours is guaranteed to match what a visitor is actually offered.
How Does Huddle Up Prevent Overselling a Seat?
By making the database itself the backstop rather than a check inside the application. A partial unique index in Postgres’s serializable transaction isolation enforces one held seat per participant per huddle, and claiming a seat locks the session’s own row first, which is what serializes two people racing for the same last seat. Releasing a held seat, or raising a session’s capacity, promotes the head of the waiting list automatically, inside that same transaction.
How Does Huddle Up Handle Time Zones and Daylight Saving Correctly?
Every timestamp is stored in UTC and rendered through the one Time Zone Service, never a raw date library call from feature code. That module owns every DST-safe calculation against the IANA Time Zone Database, the reference dataset nearly every scheduling system relies on, so a meeting agreed in one season still resolves correctly for every participant after a transition, in their own zone.
The Frontend and Backend Stack
The frontend is Next.js using the App Router with TypeScript and Tailwind, rendering as much as possible on the server so the marketing page and every guest-facing page load fast and work before any client JavaScript finishes. Interactive surfaces, the calendar picker and the live vote grid, are Client Components layered on top of that server-rendered shell. Public guest surfaces and the authenticated organiser dashboard live in separate route groups, so a guest page never carries organiser-only code or data.
The backend runs on Supabase, providing Postgres, authentication, and real-time messaging in one platform, with Drizzle as the only way application code touches the database. Row-level security is enabled on every table: an organiser can only read or write their own huddles, and a guest’s signed token, verified server-side on every request, only ever grants access to the one participant row it names. Outbound notifications are sent through SendGrid as part of the same workflow automation pattern we use elsewhere, logged as sent, skipped, or failed, and a busy organiser can switch to a digest instead of one email per response. The same signed-token approach also carries over into how the product connects to a calendar, which is a standard API integration problem regardless of the specific provider on the other end.
Why Huddle Up Is Now One of Bitcot’s Accelerators
The scheduling core, the Availability Engine, the Capacity Ledger, and the Guest Identity pattern for account-less token-based access is now part of Bitcot’s accelerator library: a set of pre-built, production-tested modules we can adapt for a new client rather than starting from a blank architecture. A future custom software or SaaS development engagement that needs waitlist logic, seat capacity, or guest-facing booking without an account requirement starts from a foundation that has already run through an ADLC-governed test cycle, rather than from zero.
That is a direct, practical outcome of building this project under ADLC rather than as a one-off. The same deep-module boundaries that made the agentic loop safe are what make the resulting code reusable across clients, since a module with no hidden dependency on one app’s database schema can be dropped into another.
What This Means If You’re Evaluating Coding Agents for Your Own Build
The test is not whether your team is comfortable with AI writing code. It is whether your hardest logic can be isolated into something a fast, local test suite can verify without a browser, a database, or a live network call. If it can, that logic is a reasonable candidate for a governed agentic loop, with a human reviewing the boundary where it meets real data. If your hardest logic is tangled through database queries, external API calls, and UI state in the same function, that is the part that still needs a person writing every line, and the more useful first project is separating it into something testable before an agent ever touches it.
That separation was not incidental to Huddle Up. It was the precondition for everything else in this post.
Frequently Asked Questions
What is a running agentic loop in software development?
A running agentic loop is the cycle a coding agent executes on its own: writing a code change, running it against a test, reading the result, and revising, repeating until the code passes or a retry limit is reached without a human approving each individual step. It works best against fast, deterministic tests and becomes risky against slow or side-effecting operations like a live database write or a real email se
What is ADLC, the Agentic Development Lifecycle?
ADLC is the governance layer placed around an agentic loop: it defines which parts of a codebase an agent may iterate on unsupervised, what test suite has to pass before a change counts as done, what gets logged for audit, and where a human review gate sits before agent-authored logic reaches production data or real users. It turns an agentic loop from an experiment into a repeatable part of a professional engineering process.
What makes an application safe to build with coding agents?
Isolating the riskiest logic into small, pure modules that take plain data in and return plain data out, with no database call, network request, or browser dependency inside the module itself. That isolation lets a coding agent get a fast, deterministic pass or fail signal from a local test run, so a wrong answer surfaces as an immediate failing assertion instead of a bug discovered later in production.
How does Huddle Up let a guest answer without creating an account?
Every invite link carries an opaque, signed participation token. Opening it sets a private, huddle-scoped cookie so the guest owns exactly one participant row without logging in. Once they submit a name and email, a private edit link with their own token is also emailed to them, so their answer survives a cleared cookie or a different device.
How does Huddle Up guarantee a sign-up sheet never oversells a seat?
Claiming a seat runs inside a single database transaction that locks the session’s own row first, which is what serializes two people racing for the same last seat. A partial unique index in Postgres backs this up as a second guarantee, so only one held claim per participant per huddle can ever exist, enforced by the database rather than by application code that a race condition could slip past.
