Metas

The problem and constraints

Metas exists to turn a client company’s own financial and operational numbers into a single, comparable score, month over month, across every area of the business and every company in a group. The client sets a target and a weight for each indicator; a person or a system reports what actually happened; the platform turns that into a score that management can compare across dozens of areas and, for a multi-company client, across every subsidiary at once.

The first constraint was that “get the number” means something different for every client, because no two clients run the same systems or grant the same access. Some clients have a modern API and are happy to hand out a key. Some run older, on-premises software with no API at all, but will allow a read-only database account behind a VPN. Some, for regulatory or infrastructure reasons, will not open any door at all beyond what a person can already see on their own screen. A platform that only knew how to call an API would simply be unable to serve a meaningful share of the clients this product exists for.

The second constraint was that a client’s organization rarely maps onto a flat list of “companies.” A holding company owns subsidiaries, a subsidiary has its own business units, and each level needs its own indicators, its own targets, and its own roll-up into the level above it, while a single person managing the whole group needs to see all of it at once without switching between separate logins for each entity.

The third constraint was that a score feeds real decisions the client’s own management makes about a team’s performance and, at some clients, that team’s compensation, far beyond a cosmetic dashboard number. Getting a formula subtly wrong, or letting a stale or manually-fudged number slip in unnoticed, doesn’t just look bad on a chart, it produces a wrong real-world decision downstream.

The last constraint was access itself, in the most literal sense. Reaching a client’s real numbers sometimes means normal software work (calling an endpoint), sometimes means acting as a network engineer (standing up and maintaining a VPN tunnel into infrastructure nobody on the client’s side can fully explain), and sometimes means acting as a data archaeologist (reverse-engineering what a legacy system’s own screens are actually showing, when the system itself won’t tell you).

Architecture

A client’s organization lives as a self-referential tree of Company rows: a holding company, its subsidiaries, and their business units are all the same kind of record, distinguished only by a category field and a parent pointer, so the same schema serves a client with one legal entity and a client with a four-level group without any special-casing. Users are attached to one or more companies through a join table, and an ordinary user’s access is scoped strictly to the companies they’re actually attached to. One role sits outside that scoping entirely: a cross-company administrator who can see every client’s structure at once, the role a consultant managing several client relationships actually uses day to day.

Underneath every company sits a set of Areas, and underneath every area a set of Indicators, each with a weight and one of five scoring formulas (a plain ascending ratio, a descending one, a cost-savings variant, and two deviation formulas for over- and under-shooting a target). An indicator’s monthly value can arrive in one of two ways, tracked by a single is_manual flag: someone types it into the dashboard by hand, or it’s written by whichever integration mechanism that specific client uses. Both paths feed the exact same downstream formula engine, so the platform never has to know or care, at scoring time, where a number originally came from.

That second path, the integration itself, is where most of the real engineering cost lives, and it’s three separate mechanisms, chosen per client based on what that client’s own systems will actually allow a third party to do. Where a client exposes an API, the integration is a straightforward scheduled call. Where a client permits database access but has no API, the integration is a read-only query running over a VPN tunnel built specifically for that client. Where neither exists, and a client’s own staff can only see numbers through their own software’s screens, the integration is RPA: driving that software the way a person would, to extract the same numbers a human operator would have typed in by hand anyway.

Once a value lands, an area’s own score follows a deliberately blunt rule: the weighted result only counts at all if the area’s aggregate outcome clears 80% of its target; short of that, the area’s score is exactly zero rather than a fraction of one. That zero, or that score, rolls up through the company tree the same way the company structure itself does, so a holding company’s dashboard reflects real performance at every subsidiary underneath it, beyond whatever happened to be typed in most recently.

A missed target isn’t left as a bare number, either. Whoever owns an indicator that came up short attaches a written justification for that specific month, and can back it with supporting evidence, a document, a screenshot, a spreadsheet, uploaded and tied to that same indicator and month. Neither the justification nor the evidence changes the score itself; the formula and the 80% floor run exactly the same either way. What they change is what a reviewer sees sitting next to a red number: not just that a target was missed, but the specific, dated explanation the area’s own owner gave for why, on the record, the same month it happened rather than reconstructed from memory later.