Roadmap

What is being considered next

Grouped into near, later and probably not. There are no dates on this page, no quarters, and no commitments. A roadmap with dates from a one person team is a work of fiction, and this one is trying not to be.

Nothing here is a promise. Do not buy this product for something on this page.

A spreadsheetone path, your own assumptions, no reactionAsking a modela plausible paragraph, no mechanism, no repeatA consultanta real answer, six weeks later, onceA twina range, a mechanism, and you can ask again tomorrow

Read that note again, because it is the whole point of the page. Nothing below is committed, dated or guaranteed. Buy the product for what the build status page says is built today. If an item here is the reason you would buy, say so on the contact page and you will get an honest answer about whether it is close, rather than an encouraging one.

Near

Things being worked on or next in line

Each of these is a known gap that people hit in the first hour, and each is small enough to be a credible next piece of work.

Known gap

Reading a scanned PDF

Today a PDF with no text layer is refused with a clear explanation and a suggestion to paste the numbers instead. Running optical character recognition over the page images would turn a scanned set of accounts into a usable source. The obstacle is that OCR needs either a binary on the server or an external service, and the second one means content leaving the machine, which needs to be an explicit choice rather than a default.

Known gap

Scoped API tokens

The REST namespace is open on Boardroom and Enterprise, but it authenticates as a signed in WordPress user, so driving it from a script means holding a session. Scoped tokens, per token rate limits and a documented endpoint set would fix that.

Known gap

The network on a thin graph

Today a graph with too few labelled nodes trains a model that cannot beat guessing the average, and the page says so honestly rather than showing a confident number. Better would be to borrow structure from the self supervised head so that risk and impact are still usable with twenty nodes. That is a real modelling problem rather than a setting, and it is the first thing being worked on.

Headcount and calendar imports

A payroll export or an HR system extract would set departments, costs per head and start dates without anybody typing them. A calendar of contract renewals would replace the current assumption that renewals are spread evenly through the year, which is one of the quietest sources of error in any customer question.

Better handling of awkward spreadsheets

Merged cells, pivot layouts, multiple tables on one sheet and summary rows that look like data. All of these read badly today and all of them are common in the files people actually have. Unglamorous, and probably worth more than anything else on this page.

Later

Larger pieces that need the near list done first

Per segment elasticity fitted from real price history

Elasticity is the single most load bearing default in the model and today it arrives as one industry prior for the whole company. Given several years of price and volume by segment, it could be fitted rather than assumed, and fitted separately for a price led segment and an anchored one. That would narrow the band on every pricing question more than any other change available.

Multi entity twins

A group with four operating companies is four twins today, with no way to model shared overhead, transfer pricing, or a decision in one entity that moves demand in another. Doing it properly means the graph has to hold entities as first class things, which is a real piece of work rather than a setting.

Scheduled re-runs against live data

A saved scenario that re-runs monthly as new actuals arrive, comparing what happened against what the model expected and flagging the tripwires that have fired. This is the feature that would turn a twin from a one off analysis into something you keep. It depends on the API and on an import path that does not need a human, so it sits behind both.

Richer competitor behaviour

Competitors match part of your move, late, and once. That is a defensible default and it is not intelligence about a particular firm. Given real competitor pricing history, a competitor could have a fitted reaction function instead of a prior, which matters most for the price questions people arrive with.

Probably not

Things this is not going to become

Listed so nobody waits for them. Each one is either a different product, a contradiction of something promised elsewhere on this site, or a thing that sounds good and models badly.

Benchmarks built from customer data

This is the obvious business model for a product that holds financial statements from many companies, and it is ruled out by the promise made everywhere else on this site: nothing is shared between accounts and nothing is aggregated. That promise is worth more than the feature.

Per employee modelling

Simulating named individuals with their own behaviour, at the level of who is likely to leave. It would be a different product, it would need data most companies should not put into a simulation, and the aggregate behaviour the engine already models is closer to what the decisions actually depend on.

Workflow and process simulation

Modelling the operational flow of a business, queue by queue and handoff by handoff. There is real value in it, and it is a discrete event simulation of a different kind with a different input format. Claiming it as a near term extension of this would be dishonest.

Learning from outcomes across customers

A model that improves because it saw what happened at other companies. Same objection as benchmarking, plus a calibration problem: outcomes from companies you cannot see are not evidence you can check. The network trains on your own twin, on your own server, and that is where it stays.

A much larger network

Twelve hidden units is not a limitation waiting to be lifted. A wider model on a graph with a hundred nodes fits the noise, and it loses the property that makes every score come apart into inputs you can trace to a file. The size is a choice and it is not being revisited.

Mobile apps

The interface is responsive and works on a phone for reading a brief. A native application for a tool people use at a desk with spreadsheets open is effort spent in the wrong place.

An agent that makes the decision for you

The output is deliberately a brief with a band, a mechanism and a list of assumptions, because the point is to give a person a better argument. Software that returns a recommendation and hides the reasoning is the thing this was built against.

How things get onto this page

Mostly from people hitting a wall. A feature request gets answered, and then either appears here or is told no, with the reason. Nothing is added because it would look good on a comparison table.

When something moves from this page into the product, it gets a dated entry on the changelog and a line on the build status page, and it stops being described here. When something is abandoned, it moves into the probably not group rather than quietly disappearing.

If an item here is the difference between buying and not buying, say so. The answer will be a real assessment of how close it is, including the answer that it is not close and you should not wait.

Buy it for what exists today

The build status page is the honest inventory: every capability the site mentions, marked built, partly built or not built, including the two things that have never been tested in production.

What is built and what is notContact