Why is a simple data change so hard?

Recently, I started working on a tool I believe should exist: a way to manage spreadsheets and structured data by describing changes in a chat and uploading reference files. The idea came from wanting to make everyday tasks (updating records, reorganising columns, or producing reports) easier to carry out.

My first attempt.

My first instinct was to build an LLM wrapper that would convert user prompts into SQL queries. During my experiments, three problems stood out:

• Delay: the conversational workflow felt slow compared with running a query directly.
• Missed changes: some instructions were left unapplied.
• Poor recovery: when the workflow broke, I had no useful fallback beyond starting over.

Those experiences made me question whether generating SQL was enough. The tool also needed to check what had changed and preserve a way to recover from mistakes.

A report in milliseconds.

Imagine a marketer organising campaign data in Excel, or a merchant updating a catalogue from a supplier’s file. They understand their business, but translating that knowledge into formulas, filters, or scripts can take hours.

A developer might handle the same task with a short query or a small program. I want to make that level of control accessible through the language people already use to describe their work.

For example, a merchant could ask:

Show me September’s sales by category, including the number of orders and units sold, with the highest-selling category first.

A developer could express that request in SQL:

-- September sales report by category
SELECT
    p.category,
    COUNT(DISTINCT o.id) AS orders,
    SUM(oi.quantity) AS units_sold,
    ROUND(SUM(oi.quantity * oi.unit_price), 2) AS sales_mad
FROM order_items AS oi
JOIN orders AS o ON o.id = oi.order_id
JOIN products AS p ON p.id = oi.product_id
WHERE o.created_at >= '2026-09-01'
  AND o.created_at < '2026-10-01'
GROUP BY p.category
ORDER BY sales_mad DESC;

Measured execution: 58 milliseconds, including result retrieval, on 100,000 synthetic order lines in a local, in-memory SQLite demo. This measures the already-written query; interpreting the request takes additional work, and real-store timings will vary.

Changes need more control.

A report reads data. Updating it introduces decisions that the system must get right:

Update the prices from this supplier file, keep our existing product names, and show me anything you cannot match.

To carry out that request reliably, the tool needs to:

1. Match supplier records to the correct products.
2. Change prices while preserving existing names.
3. Present uncertain matches for review.
4. Verify the applied changes and provide a recovery path.

That is why I’m building OrbitRows: to help people turn business instructions into controlled operations on their data. The project is still in development, with speed, accuracy, review, and recovery guiding the work. I want people to spend less time maintaining spreadsheets and more time using the information inside them.