Pixel-Perfect Planning

Somewhere in the finance department of one of the world's largest pharmaceutical companies, there lived an Excel file.

It was 700 megabytes. It had hundreds of sheets. It had macros. It had VBA code. And it had exactly one person in the world who fully understood it. A developer who had, over the years, turned a planning spreadsheet into something that was, by all accounts, a genuine work of art.

The problem was obvious even if nobody wanted to say it out loud: if that person ever left, the global planning operations of a multi-billion-dollar company would grind to a halt. No knowledge transfer. No documentation sufficient to explain what lived inside it. Just a very large file and a lot of confused finance controllers trying to reverse-engineer decisions that had been encoded in formulas years earlier.

That's not a planning system. That's a single point of failure wearing a suit.

It wasn't the only warning sign. The company already had TM1 deployed in pockets across the business, isolated islands of structured planning that had never quite connected into a coherent whole. The rest of the organization still relied on fragmented Excel files with no version control, no access management, and no audit trail worth the name. When plans changed, someone updated a file. When that file conflicted with another file, a meeting was called. When the meeting produced a decision, someone updated a different file. The cycle repeated quarterly, indefinitely.

They knew they needed to change. They'd known for a while. The technical backbone, TM1, was already there and already trusted. What they didn't have was a front end that their users would actually want to open, that would bring the different planning functions together into something coherent, and that could handle the scale and complexity of a global pharmaceutical operation without requiring a specialist to run it.

The other complication was scope. This wasn't a single planning team with a single planning need. It was diagnostics and pharma divisions with different planning horizons, different data sources, different user bases, and different definitions of what a "plan" even meant. Short-term sales forecasts for thousands of hospital clients. Thirty-year lifecycle models for drugs still in Phase 1 trials. R&D pipeline projections where the statistical failure rate is built into the model by design. These are not problems with a single off-the-shelf answer.

We were brought in as the front-end and UX partner for a suite of planning applications covering both the diagnostics and pharmaceutical sides of the business, a scope that expanded over time as the two divisions began merging operations.

The portfolio now covers six distinct planning domains.

Short-term sales planning. A granular application for planning what gets sold, to whom, at what price, and in what volume, across thousands of products, hundreds of hospital and institutional clients, and dozens of markets worldwide. Salesforce and Snowflake data feed into the TM1 backbone, so early-stage sales leads carry probability-weighted values and flow directly into consolidated global sales forecasts. Sales representatives around the world contribute to the group-wide plan without needing to understand anything about the architecture underneath them.

Long-term business case planning. A module for modeling the commercial lifecycle of products still in R&D, not yet on shelves, but requiring financial projections that span 30 to 40 years. Development timelines, regulatory approval phases, go-to-market assumptions, and plateau revenue modeling, all in one place, value-based rather than unit-volume-based.

Base business planning. The counterpart to business cases: planning for the products already on the market and already generating revenue. Similar time horizons, similar structure, but tracking actuals against original models rather than projections against assumptions.

R&D pipeline planning. Probably the most consequential application in the suite. Out of roughly 150 drug candidates in development at any given time, statistically only one will reach commercial production. The rest fail. At animal trials, at Phase 1 or Phase 2 clinical testing, at FDA, EMA, or regional regulatory review. This application lets R&D controllers model that pipeline in real time: tracking which molecules are in which phase, assigning probability weights to each milestone, and calculating when and whether any given candidate will ever generate cash flow. When a trial fails, the status changes in minutes. The financial model updates automatically. Controllers don't have to rebuild anything from scratch.

Live P&L. A chart-heavy reporting and planning interface that brings revenues, costs, and profit into a single view with deeply customizable visualizations. Users can screenshot directly from the application for presentations, which eliminated the "export to Excel, rebuild the chart" detour that had previously consumed hours of every reporting cycle.

A redesigned legacy application. One application in the portfolio was originally built by the client's internal developers using our framework. It worked, but it was visually inconsistent and hard to navigate. We were brought in to redesign it from scratch, dividing the interface into logical segments and bringing the UX in line with the applications we'd built ourselves.

This is primarily a front-end story, which means the headline metric isn't a 4,000-hour reduction in manual work or a 10x improvement in planning cycle speed, though the latter is directionally true for several of the processes we support. The headline is something harder to quantify but easier to recognize once you've seen enough enterprise software implementations to know what bad looks like.

Nobody should hate their planning tools.

The default state in enterprise planning is that users tolerate the software. They resent it quietly. They find workarounds. They export to Excel whenever the application doesn't do exactly what they need, because it was built for a generic use case and then forced into a specific one. Power BI dashboards built by analysts drag-and-drop together something that sort of works. Native TM1 interfaces do the job with the aesthetic sensibility of 2005 enterprise software. Nobody complains loudly because the bar is low enough that clearing it feels like success.

We set a different bar. Every project we take on starts with a Figma prototype, a fully clickable, visually detailed mockup that we refine with the client until every edge case and every "oh, but we also need to..." moment is captured before a single line of production code is written. This means the requirements are real before the build starts, not aspirational.

The math on this is worth spelling out. Fixing a misunderstanding in the design phase costs roughly 1/10th to 1/20th of what it costs to fix the same misunderstanding after it's been built into the application. The standard enterprise IT pattern is build it, demo it, hear "that's not what we wanted," then rebuild it. That's why IT projects go over budget. We don't do it that way. The prototype is the specification. By the time we're writing code, what we're building has already been agreed on in detail.

The feedback from the client's project owner on the planning suite captured the day-to-day experience better than any metric could. His exact words: "I wish my food delivery app was this fast."

He meant turnaround time on requests. A bug reported Monday, fixed Tuesday. A feature discussed Wednesday, testable by Friday. The comparison to a delivery app sounds glib until you've spent six months waiting for a large ERP vendor to quote a change request at €100,000 and six months' delivery time.

We're next-day people. That reputation didn't come from nowhere.

One aspect of this work that doesn't feature prominently enough in the business case for systems like this: the R&D pipeline data that flows through the planning applications we build is among the most market-sensitive information that exists anywhere in the financial world.

A failed Phase 2 clinical trial can move a pharmaceutical company's share price by 6 to 10 percent in a single session. Information about which candidates are struggling, which are ahead of schedule, and which regulatory milestones are approaching cannot leak outside the authorized planning team. Not to competitors. Not to anyone with a trading account. Not even to colleagues in adjacent departments who have no business need for it.

We have no access to this data. That's by design and that's how it should be. Architecturally, TM1's cell-level security model allows the client to set authorization rights at the level of individual data points, something Excel cannot come close to regardless of how many worksheet protection settings you configure. A cell in TM1 can be visible to one user, editable by a second, and completely invisible to a third, all in the same model.

The move from fragmented spreadsheets to a governed planning environment wasn't primarily a compliance project. But it delivered compliance-grade data security as a structural consequence, and that consequence has real value. In an industry where a single data leak about a late-stage clinical trial can cause regulatory scrutiny, reputational damage, and material financial loss, having data governance built into the architecture rather than bolted on afterward is not a secondary consideration.

There are self-service BI tools. There are drag-and-drop planning platforms. There are products that let an analyst assemble something that looks like a dashboard in an afternoon without writing code.

We know what those products produce. We've seen enough of them.

What they produce is software that works but doesn't fit. It does the job the way a rented suit does the job: technically appropriate, subtly wrong. At small scale, the wrongness is manageable. When you push it to 500 users, the friction multiplies. Training costs increase. Support tickets accumulate. Users find workarounds, the workarounds become unofficial process, and eventually people go back to Excel because at least Excel does exactly what they tell it to.

Our framework was built on a different assumption: invest more upfront in the design and development process, and get software that users use correctly the first time without needing to be taught. That trade-off made sense from the start. It makes even more sense now.

AI-assisted development has changed the economics of what we do in a meaningful way. The expertise required to build pixel-level precision into a planning interface still lives with us. The price premium that used to come with that expertise has largely gone away. A team member described it well: we used to build Porsches at Porsche prices. Now we build Porsches at Peugeot prices. The knowledge of how to build the Porsche is still the scarce thing. The cost to the client is not.

As a side note on adoption: a separate internal team at the client uses our framework to build and maintain their own applications across use cases we're not directly involved in. The combined user base across those internal deployments runs into the thousands. That happened organically, without us selling it. It's probably the most straightforward measure of how much the underlying technology is trusted inside the organization.

If you come to us with a requirement we can't immediately fulfill, a chart type we haven't built, an interaction model that doesn't exist in the framework yet, an integration we haven't connected, you get one of two responses. Either a timeline for when we can build it, or a design proposal for how to solve the underlying problem a better way.

If you come to us with a requirement we can't immediately fulfill, a chart type we haven't built, an interaction model that doesn't exist in the framework yet, an integration we haven't connected, you get one of two responses. Either a timeline for when we can build it, or a design proposal for how to solve the underlying problem a better way.

You don't get "no."

That's not a sales line. It's a reflection of how the work actually runs. When the client's team asked for chart label customization on the Live P&L module, they asked for global label control, the ability to move all labels at once. We delivered individual bar-level label control instead, because anyone who uses charts in presentations knows that global alignment is rarely what you actually need. They discovered the capability mid-demo.

The reaction was delight, not confusion.

That happens when the team building the software has spent enough time understanding the process to anticipate what's useful before it's been fully articulated. It requires staying close to the people using the tools, understanding the workflow well enough to see around corners, and being willing to propose solutions the client hadn't thought to ask for.

It's also why we start every new module or major feature with a prototype phase rather than jumping straight into development. A three-minute video of a clickable Figma mockup, shared internally by the client's project owner with their colleagues and leadership, surfaces more genuine feedback than any requirements document. People respond to things they can see and interact with in a way they don't respond to written specifications. By the time we're writing code, the important decisions have already been made and tested against real user reactions.

That process is slower at the front end. It's significantly faster at the back end, when there are no surprises in the build and no rework triggered by a demo that landed wrong. In enterprise software, that's where most of the time and money actually disappears. We'd rather spend it earlier, where it costs less to fix.