Tools that refuse to forget

A note on why GaleFranco Labs exists, and what the three things I'm building have to do with each other.

The thing software keeps losing

For most of the last decade, I've had a quiet suspicion that most of the software we use is failing us for the same reason, and I finally have enough evidence from my own work to say it out loud.

The reason isn't features. It isn't design, exactly, though design is downstream of it. It isn't AI, or the lack of it.

It's that the software forgets.

It forgets where a shopping cart came from by the time the invoice arrives. It forgets why a meeting was scheduled by the time someone's rescheduling it. It forgets what a decision was made for by the time someone's questioning it six months later. It forgets how a family got from a Saturday morning plan to a Sunday night argument. It forgets why the architecture diagram on the whiteboard was drawn the way it was drawn, and whether the reasons still hold.

Every tool I've seriously tried to build in the last few years has turned out, eventually, to be a tool against that forgetting. I didn't plan it that way. I thought I was working on procurement, and then I thought I was working on a 3D design canvas, and then I thought I was working on something to help my own family hold together. The thread only became visible once I had all three on the table at once.

The thread is this: most software is happy to move information from one place to another. What almost none of it does is preserve the context in which that information was first meaningful.

This essay is about why that gap exists, why it matters more than it looks like it matters, and why I've decided to spend the next chapter of my career building tools that try to close it.

The "mystery invoice" problem, and what it's really about

Here's a tiny example from one of the ventures I'm working on, OriginID. It sounds like an accounting problem. It isn't.

At a typical mid-sized enterprise, somewhere between thirty and fifty percent of indirect spend happens through some combination of e-commerce sites, procurement platforms, EDI systems, and the finance team's ERP. The buyer at the field office clicks through to a supplier website, fills a cart, hands off to the procurement system for approval, which routes through an EDI connection to the supplier, which ships, which eventually sends back an invoice that lands in the finance team's queue.

At each step of that handoff, something invisible happens: critical context about why the purchase was made (what project, which cart, which approval path, which pricing tier, which GL code) gets stripped out because the next system in the chain wasn't designed to hold it.

The finance team ends up with what the industry calls, very honestly, "mystery invoices." Bills they can't match to purchase orders. A typical enterprise has someone spending thirty minutes on each of these, trying to excavate a decision that was made three weeks ago by someone they've never met. An enterprise with five hundred million dollars of indirect spend loses something like two and a half million dollars a year to this.

Now, nobody designed it this way. No procurement team wakes up and says, "Today I'm going to throw away context." It happens because every system in the chain was optimized for its own job, and the context got dropped in the cracks between them.

OriginID is, on the surface, a patentable (our current IP strategy is extensively researched and ready to implement) cart lineage technology that embeds an unbroken digital identifier from the moment of cart creation all the way through payment, so the finance team can reconcile in seconds instead of half an hour. Underneath that, though, it's an argument: that the way to fix the mystery invoice problem isn't to throw more people or AI at it after the fact. It's to refuse to let the context get lost in the first place.

Once you see the pattern, you start seeing it everywhere.

The flatland problem

Here is the same observation from a completely different direction.

When I sit down to plan something complicated (a system architecture, a business model, a process redesign, a product roadmap), I reach for the same flat rectangles my predecessors reached for in 1985. Boxes and arrows on a whiteboard. A Google Doc. A Miro board. A Figma file. Flat surfaces, made for flat ideas.

The problem is that the ideas aren't flat. A business process has a time dimension that the flowchart can't really show. A software architecture has dependency densities and feedback loops that the boxes-and-arrows diagram compresses into lies. A strategic plan has multiple parallel futures that a linear roadmap has no language for at all.

So you draw a simplified version. Then you present it to someone, and they ask a question that requires the dimension you flattened, and you say, "yeah, that's not quite in the diagram, but trust me." And everyone nods, because they've all been there too.

What we're losing, every time, is the context in which the plan actually made sense. The diagram captures the what; it throws away the why, the when, and the "what would it look like from the other side."

Vectra is my attempt at the opposite: a three-dimensional canvas where you can map a process onto a sphere and rotate it to find the cyclical structure you couldn't see in the flowchart, where you can extrude a project plan along a time axis and slide through it to watch the resource conflicts appear and resolve, where you can wrap a paradoxical system around a Möbius strip and see what it actually looks like. It's a thinking tool for problems that refused to be flat.

The pitch I like best for it is: your problems are three-dimensional. Your tools should be too.

The deeper claim underneath the pitch is the same one I'm making about mystery invoices. The tools we use shape which parts of a problem we're allowed to think about. Every dimension the tool drops is a dimension the thinking drops. And most of our tools, for most of our hardest problems, drop way too much.

The family as a system

The third venture is the one that will sound like it doesn't belong, until you look closely.

Gather is a consumer product: "The Digital Family Table." It unifies a family's calendar, tasks, chores, meal plans, goals, memories, and an ambient communication layer that lets anyone comment on anything and have the conversation stay attached to the thing it was about.

The feature I'm proudest of isn't any of the obvious ones. It's the part where, six months from now, you can open a meal plan for a week in October and see the conversation your family had about that meal plan, in context, with the voice note your teenager left about the new vegetarian thing they're trying and the reply your partner left about the grocery budget — not buried in a Slack channel, not lost in a group text, but still attached to the artifact the conversation was actually about.

I built that feature because I watched my own family, and many families I know, lose entire threads of their own history to the fact that the conversation happened in one app and the thing the conversation was about lived in another. Nobody was forgetting on purpose. The software just wasn't designed to remember.

Gather, underneath the warm and friendly surface, is the same argument I'm making in enterprise procurement and systems design, applied to the most important context any of us carry: the context of our own family life. If you let a family's decisions get detached from the reasons they were made, you don't just lose data. You lose the quiet accumulation of shared sense-making that makes a family a family instead of a household.

The product is supposed to feel warm. The thesis underneath it is exactly as serious as OriginID's.

Why a studio

These three ventures live under a single roof, GaleFranco Labs, because they're three faces of the same bet:

That the next decade of software progress isn't going to come from better features. It's going to come from a refusal to let context be lost.

I'm betting that in ten years, the tools we'll remember as important are the ones that treated continuity, lineage, memory, and "why" as first-class citizens instead of things to bolt on afterward. I'm betting this in three very different domains (enterprise, abstract systems, family) not because I couldn't pick one, but because the argument is stronger if it survives translation across all three.

I've structured GaleFranco Labs as a studio rather than a single-product company on purpose. A studio can follow a thesis across domains. A single-product company has to flatten itself into one market's language, which is the thing I'm trying to push against.

The trade-off is that a studio of one moves slower than three dedicated teams would. I'm accepting that trade-off because the alternative (spinning out three separate companies that each pretend to be unrelated) would lose the single thing that makes any of this interesting, which is the thesis they share.

What I'm building toward

Concretely: I'm building three products, publishing the thinking behind them, and working in the open as much as I can.

OriginID is my most commercially serious bet. Vectra is my most conceptually serious bet. Gather is my most personally serious bet. All three exist simultaneously because I believe they're the same bet told three different ways, and I'd rather find out whether I'm right about that than hedge it by doing only one.

If you're reading this and any of it lands — if you're wrestling with a system that keeps losing context on you, if you're trying to think about a problem your current tools aren't letting you see, if you've ever felt your family's history slipping into a chat log nobody's ever going to read again — I'd love to hear from you.

Thanks for reading.

— Brian