Loading
FoundryPulse is the system FlowFoundry runs its own business on. We built it for the ordinary reason a business builds internal software: the spreadsheets worked until they did not. It is included here because it is the most honest example we can offer - we are the client, we absorb every design mistake ourselves, and it demonstrates the same architecture we propose for operational portals. In active development and used daily.
Leads sat in one sheet, projects in another, allocation in a third, and the connection between them existed only in the founder's head. Answering a basic question - who is over-allocated next week, which leads went quiet, what is the status of a client's work - meant opening several files and reconciling them by eye. That is exactly the condition we tell clients to fix, and continuing to operate that way while advising against it was not defensible.
The brief, before any technology was chosen.
Described in layers, because that is how the design decisions actually separate.
Leads, clients, projects, milestones, tasks, people and allocations as first-class related entities. The relationships are the point - they are what a spreadsheet cannot express.
Leads and projects move through explicit states with defined permitted transitions, so status means the same thing to everyone.
Capacity modelled per person per period, with committed allocation compared against it so over-commitment is visible before the week starts rather than after it fails.
Postgres via Supabase with row-level security. A team member sees their own tasks and allocations, not the full commercial picture.
Dashboards query live data directly. There is no export step, which is what keeps the operational number and the reported number identical.
Meaningful changes write an entry with actor and timestamp, so a disputed status change can be traced.
Pipeline with ownership, stages, activity history and follow-up prompts.
Projects, milestones, tasks and dependencies with delivery status.
Capacity versus commitment per person and period, with over-allocation flagged.
Client records linked to projects, contacts and communication history.
Assignment, priority, due dates and completion tracking.
Live pipeline, delivery and utilisation views with no export step.
Founder, lead and team-member permission sets over shared data.
Attributed, timestamped record of meaningful changes.
The problems worth writing down, and how each one was handled.
Extraction was trivial; deciding what half-filled rows meant was not. We resolved ambiguity deliberately during migration rather than importing it, because importing it would have made the new system untrustworthy on day one.
Capacity is not hours available. We model committed allocation against realistic availability, excluding the coordination overhead that made earlier estimates consistently optimistic.
The internal-tool failure mode is data entry with no payoff. We kept required fields minimal and made the allocation view genuinely useful, so updating it serves the person doing it.
Dashboards read live data rather than a snapshot. Every export step is a chance for the reported figure to diverge from the operational one.
Sequence matters. Each step was chosen because it de-risked the next one.
Time to answer an allocation question
Pending measurement
Minutes from question to answer, baselined against the spreadsheet process
Leads without an owner
Pending measurement
Share of open leads with no assigned owner
Over-allocation caught before the week starts
Pending measurement
Conflicts surfaced in advance versus discovered during delivery
Reporting preparation time
Pending measurement
Hours spent assembling operational reports per month
No. It is internal software shaped around how we specifically work, and that specificity is the reason it fits us. We share the architecture because the pattern transfers; the product would not.
Because we can be completely open about it. There is no client to protect, so we can describe the design mistakes and the migration difficulties honestly - which is more useful to someone evaluating us than a polished summary would be.
Describe the system you have in mind. We will tell you what it takes, what we would do differently, and whether we are the right team for it.
