A software agency running about 20 programs at once
Digital Horizon builds and maintains around twenty client applications side by side. This is how it runs them from one plan: meetings that sync into the work, check-ins that happen on their own, and coding agents reading the same tickets the team does.
Beta workspace · Dubai
Digital Horizon
A software agency building websites, apps and integrations for clients. It is the company Falrow was first built for, and the first workspace that ran the whole of it: every client application, every client call and every agent session in one place.
Four things carry the whole studio
An agency at this size does not fail on any one build. It fails in the gaps between them: the note nobody moved into the tracker, the client who found out late, the agent working from a plan that was true last week.
Twenty client builds, not twenty trackers
Every client build is an application: its own tech stack, repository remote, ticket-type owners and cycle schedule, all inside one workspace. A studio running twenty programs at once stops paying the tax of twenty separate tools and twenty different definitions of “in review”.
- Tech stack and repository on the application record
- Cycle schedules per client, not one studio-wide sprint
- Bugs routed to the owner of that ticket type
The call syncs into the plan
Meeting notes come in from Granola and land on the client they belong to. The action items in them become tickets, linked back to the call they came from, so the thing a client asked for on Tuesday is in the right backlog with its context attached instead of in somebody’s notes app.
- Granola import onto the customer record
- Action items become reviewed, linked tickets
- Backlinks from the ticket to the meeting
Checking in without remembering to
Because the client, the call and the work sit on the same records, the check-in is a by-product of the plan rather than a thing to schedule. Questions reach the client while the feature is still being built, which is what makes more of the functionality right on the first go instead of on the second pass.
- Customers linked to the applications built for them
- Open questions attached to the ticket that raised them
- Fewer rounds of rework per feature
Claude Code works from that same plan
A developer opens a client repository and asks their agent for the plan. The workspace matches the git remote to the application and hands back its stack, owners, active cycle and open tickets in priority order. Every write the agent makes carries the version it read, so nobody’s edit is quietly overwritten.
- plan_context resolved by git remote
- Version-checked writes
- The same roles and rules as the developer
Call, ticket, agent, check-in
The same four steps run on every one of the twenty applications, which is the only reason twenty is possible.
More of what ships is right the first time, because the client was asked while it was still being built rather than after it was delivered.
That is the part an agency feels: not a faster sprint, but fewer second passes across twenty programs at once.
Clients & meetingsFalrow for agenciesThe next case study could be yours
We are onboarding a small number of teams that build several applications and already code with agents. You get a direct line to the people building it.
Bring a real project, not a sandbox
We are opening workspaces to a few teams at a time, especially teams that build several applications and already code with Claude Code or Codex. Tell us what you build and we set it up with you.