We are building Pluto to answer a simple question that is surprisingly difficult for many Shopify operators: after everything, what did the store actually make?
Revenue is easy to find. Shopify shows sales. Ad platforms show spend and attributed conversions. Payment providers show fees and payouts. Product costs often live in a spreadsheet. Shipping, handling, refunds, and one-off expenses have their own systems and their own timing.
Each number can be correct on its own while the complete picture remains unclear. Pluto exists to bring that picture together.
Why Pluto?#
Most commerce software is built around activity: more orders, more campaigns, more customers, more revenue. Those numbers matter, but they do not tell an operator whether growth is healthy.
A store can have its best revenue day and still lose money. Ad spend may rise faster than sales. A popular product may carry weak margins. Refunds can make a strong week look different once they settle. Shipping and payment fees can turn a promising order into an unprofitable one.
Pluto starts from the bottom line and works backward. Revenue is one input. So are COGS, ad spend, fees, shipping, handling, refunds, and custom costs. The product is organized around what remains after those inputs are accounted for.
One view of the business#
The goal is not to replace every source system. Shopify should remain the source for orders. Advertising platforms should remain the source for campaign delivery. Pluto's job is to connect the financial facts required to understand the business.
That means a merchant can change a date range, compare channels, inspect product-level profit, or move between stores without rebuilding the same calculation in a spreadsheet. The definitions should remain consistent wherever the number appears.
The number has to be trustworthy#
Profit software has a higher bar than a typical dashboard. Merchants can compare the result with Shopify reports, ad-platform invoices, payout statements, and their own spreadsheets. A number that is almost correct is still wrong.
We treat financial correctness as an architectural requirement. Money stays decimal from external APIs through our Rust calculation layer and into ClickHouse. Core analytics formulas live in one pure calculation crate, and the main analytics path uses those functions instead of reimplementing the math in React.
We also keep financial results out of Redis. Redis helps coordinate work such as locks and idempotency, but it is not a cache for profit. Reports read the underlying facts, while the sync layer is responsible for keeping those facts current.
Freshness should be visible#
A combined report is only as current as the sources behind it. Shopify orders may be current while an advertising import is delayed. A green status based on the newest source would make the overall report look fresher than it is.
Pluto exposes source-level sync state and bases the combined freshness headline on the oldest connected source. Active imports, delayed data, and failed first syncs are different situations, so the product treats them differently.
This is part of a broader principle: uncertainty should be visible. Missing or unsettled data should not be hidden behind a confident number.
From dashboards to questions#
Dashboards are useful when you already know where to look. They are less helpful when the question is open-ended: Why did margin fall this week? Which products are driving the change? Did higher ad spend create profitable growth?
Ask Pluto is our attempt to make that investigation more direct. The agent works with structured responses rather than one large block of generated text. An answer can contain metric cards, tables, callouts, and supporting explanations tied to store data.
The ambition is not to make financial decisions for the merchant. It is to shorten the distance between noticing a change and understanding the numbers behind it.
Built for operators#
Pluto is designed for people who run the store, not only for analysts. The interface should feel calm, load quickly, and explain itself without requiring a reporting project.
That preference affects small decisions: fewer decorative charts, clear metric definitions, visible data freshness, flat pricing, and no artificial complexity added to make the product look more powerful.
It also affects the architecture. Operational state lives in Postgres. Analytical facts and rollups live in ClickHouse. Long-running imports run in the background. The browser talks through a Next.js BFF rather than calling internal services directly. Each choice is intended to keep the product dependable as stores and datasets grow.
What comes next#
We will use this blog to explain what we build and why. Some posts will be for Shopify operators: attribution, data freshness, profit formulas, and the practical details behind the numbers. Others will go deeper into Rust, ClickHouse, sync engines, financial testing, and the agent runtime behind Ask Pluto.
The common thread is simple. Profit reporting should be clear enough to use every day and rigorous enough to trust when the number matters.
Hello, Pluto#
Pluto is being built around what a store keeps, not only what it sells. There is a great deal left to build, test, and explain. This is where we will share that work.
Questions or sharp takes: join Discord or email hello@plutoprofit.com.