Ask a question, get an answer from your own data
We connected Lilla to a database. Ask a question you would normally send to someone technical, and you get the answer back in about a minute, in plain language.
Why we built this
Your business already stores the answer to most questions you ask. Revenue by product last quarter, which customers slowed down, which invoices are late, where jobs keep running over. It is all in the database behind your systems.
Getting it out takes a person. You ask someone technical, they write a query, and the answer comes back a few days later. By then you have usually made the call without it. Smaller questions never get asked at all, because they are not worth interrupting anyone for.
So we connected Lilla directly to a database. You ask in plain language and get the answer while you are still thinking about the question.
A demo you can look at
We tested this on public data rather than a client's, so we can show it. The database holds Singapore HDB resale transactions: several hundred thousand property sales with town, flat type, size, remaining lease and price.
The same connection runs against your own sales, customer or support records. The questions that follow are about flats, and each one has an equivalent in a business.
What this looks like in use
Finding the outlier in each period
You ask:
What was the most expensive flat for each year, in 2024, 2025 and 2026?
On your own data this is the largest order of each quarter, the biggest invoice per client, or the deal that set the record for a region.
The result: an answer in seconds, with the supporting detail already attached.
Answering a question with conditions attached
This is the one a property agent would ask before a client meeting:
What prices should my client expect for a 4-bedroom HDB in Pasir Ris? The flat should not be older than 10 years and not above 800k.
Three conditions, none of them a column in the database. Lilla works out what "not older than 10 years" means in lease dates, separates the last twelve months from the full history, and says which part of the range comes from higher storeys. It also says how many records the answer rests on, and which ones drag the average down.
The result: a number to quote, and the reasoning to defend it when the client pushes back.
Pointing it at your own tables
Most companies already have some version of these:
Customers
Orders
Invoices
Products
Projects
Support tickets
Subscriptions
Inventory
You ask:
Which customers should we pay attention to this month?
Lilla combines order history, revenue movement and support activity, then explains why particular accounts stand out. A standing report would show you the top ten by revenue and leave you to notice that number four has quietly halved.
The result: the pattern gets named for you.
Where teams use it
Sales
Which products and segments are growing, and which are flat once you remove one large account.
Finance
Which invoices are overdue, and which customers carry the largest exposure this month.
Operations
Where delays happen most often, and whether the cause is one site, one supplier or one shift.
Customer service
What customers contacted you about this quarter, ranked by how often each issue came up.
A dashboard answers the questions you knew to ask when you built it. Most of these arrive once, get answered, and are replaced by a different question next month.
What is new here
Software that turns a sentence into a database query has existed for years, and it was never much use, because one question rarely maps to one query. The Pasir Ris answer above needed several: what counts as a ten year old lease, what the last twelve months look like against the full history, how storey height moves the range, and whether 458 records is enough to say any of it. Deciding which of those to run, reading them together and noticing that the average is dragged down by older sales is the part that used to need a person.
That is the part Lilla does. It is why you can ask the question directly instead of commissioning the analysis.
How it works
The dashed boxes are the database connections. They are read-only and limited to the tables you allow. Everything between the question and the answer is work someone would otherwise do by hand.
Access and checking
The pilot does not print the queries next to the answer. We keep them, along with a record of what was read to produce each number, so anyone technical on your side can ask for both the first time an answer surprises you.
The same setup works with PostgreSQL, MySQL, SQLite and other standard databases, built around the questions your business asks and the access rules you want in place. If you want to see it running against your own data, get in touch.