Folkware

Folkware started with conversations, not software. I spoke with the people who keep building businesses running: owner-builders, contract administrators, project and site managers, estimators, sales directors and trades, from a one-person joinery shop to commercial builders delivering defence and government work. Every session was about a real job, never a pitch: walk me through yesterday, what did you chase, what was the last thing that slipped, and what did it cost you.

From those conversations I mapped a job end to end, from the first enquiry to the final payment, and marked where the time goes and where the money quietly drops out. The same handful of findings came back in almost every conversation, whatever the size of the business, and each one is now a rule somewhere in the products. Open one to see what it changed.

Folkware started as two products that did not know about each other. Rory was an AI admin assistant that read a builder’s email and tools and chased the money. Footing was the job and project platform those tools fed. Each was useful, and each kept running into the same wall: the job did not start where they started.

A builder’s job starts with a tender or an enquiry, gets priced off a set of plans, gets built, and gets paid, and every hand-off in that chain is a person retyping something. So I stopped building single products and designed a crew. Each app takes one shift of the office, hands the job to the next, and stands on the same record underneath. Benny finds tenders and puts the bid together. Eddy reads the plans, measures the takeoff and builds the quote. Rory chases every variation, claim and invoice until the money lands. Footing is the ground they stand on.

The rule I set from the start, and the one that made every later decision easier, was that each app has to stand on its own. A builder can hire just Eddy, and Eddy is complete. Bring in the rest and the job moves from tender to paid without anyone typing it twice.

The architecture question was whether a crew means one big app or four small ones. I went with separate apps on one platform. Each has its own brand, its own domain and its own home screen, because a builder hiring an estimator wants an estimator, not a tab in someone else’s product. Underneath, they share one company account, one sign-in, one company record of certificates, people, suppliers and rates, one chase engine, and one bill with a line per app.

Each app is switched on per company, and every link between them asks first. If Eddy is off, Benny shows a price form instead of a “Price this tender” button. If Footing is not there, Rory still works across the tools a builder already has. Tables belong to one app, and an app never writes another app’s data: it leaves an event for the other app to pick up. That rule is the reason three apps could be built in parallel without stepping on each other.

The brand had to do two jobs at once: make each app feel like a distinct character a builder could hire, and make the four of them read as one family. I drew each mascot from its own wordmark. Eddy is the blue “e” from the Eddy logo, holding a rolled plan and a pencil. Benny is the orange “b”, mirrored from the same glyph, holding up a bid paddle. Rory is the “o” in a hard hat. Same construction, same flat colour with a solid extruded edge, same props-in-front staging, so they sit together on the isometric Footing slab that appears on every site.

Each mascot has a set of moods tied to real product states, not decoration. Benny’s paddle only ever shows a tick or a dash, never a number, because bids are sealed. Its “lodged” pose only plays after a person has pressed Submit, because Benny never submits on its own. The brand carries the product’s rules.

The apps share a core design system, and each adds a thin brand layer on top. The core holds everything a builder should not have to relearn between apps: type scale, spacing, 14px button corners, 44pt touch targets on phones, one status said once, one primary action per screen, and a composer-first home where you drop the plans, the pack or the email and the app takes it from there. The brand layer is only the accent, the mascot and the voice.

I built it in code as a shared package used by Eddy and Benny, and in Figma as one library with a mode per app, so a component change lands everywhere at once. Pick an app below to see the same kit wear each brand.

Footing is the job and project platform for small-to-mid Australian builders: quoting, scheduling, subbies, variations, RFIs, progress claims, compliance and invoicing in one live view. It grew out of the same interviews, and one sentence kept coming back: you’re not short on work, you’re short on control.

So the command center leads with the work that needs a decision and the four numbers a builder can never see in one place: work in progress, projected margin, receivables, and the next thirty days of cashflow, shown in red when it goes negative. Footing is live now, priced by projects rather than seats, with a sixty-day trial and free migration.

What changed with the crew is Footing’s role. It is no longer a product that has to do everything. It is the record everything else reads and writes. Rory holds each person’s Footing alerts and briefs them three times a day, and caught variations land in Footing as suggestions under the responsible person’s own login. Eddy and Benny are built to hand their work over the same way: a won quote becomes a Footing job, and a bid starts life as a Footing lead. None of the apps need Footing, and all of them are better on it.

AI collapsed the time it takes to build software. That moved the hard question from whether I can build something to whether I should, and what it should feel like. I built Folkware solo, with AI agents doing most of the typing, and kept the judgement in a loop I run on every feature.

Rough first. A flow goes into Figma, phone and desktop together, checked against real patterns in Mobbin, and often three versions sit side by side before one is picked. In front of builders before it is committed. I watch without guiding, because where someone hesitates is the data. Then the agents build it, and every change gets a cold code review, a design review against the house rules and an accessibility check before it merges. Then I use it myself, on a real company, on a phone, on a bad connection, at the end of a long day. The seams are where AI defaults show: the transitions, the empty states, the error states, the copy read aloud. That is the layer agents cannot do for you, and what I find there goes back to the top of the loop.

The stack stays deliberately boring, so the effort goes into that layer: one TypeScript monorepo, one shared design package, and each app on its own server, so a heavy plan read in Eddy never slows a builder’s inbox in Rory.

The hardest design decision was not visual. It was saying that each app must work alone. It would have been faster to make Eddy assume Rory, or Benny assume Eddy. But a builder buys one thing at a time, and a product that only makes sense as part of a bundle is a product nobody tries. Every cross-app feature in Folkware has a standalone fallback, and that discipline is what lets the crew feel like a team rather than a suite.

The other lesson was that a family brand is earned in the details. The mascots read as siblings because they are built from the same glyph. The apps feel related because the button corners, the touch targets and the way a status is written are the same everywhere. Builders will never name any of that. They will just notice that the second app already makes sense.