Solo-Founder AI Startup: 210,000 Tenders, 24 Milliseconds

A platform across five continents, one operator

In September 2026 Google Cloud documented the infrastructure behind Lucius AI, a tender intelligence startup founded by Davor Jerković. The product helps companies assess public tenders in markets spread over five continents.

The platform tracks more than 210,000 public tenders across the United Kingdom, the European Union, India and Australia. Every night it harvests notices from thirteen procurement sources, including World Bank-funded tenders in Africa and Asia.

The operational load stays heavy. Two production regions run on Cloud Run, Europe and Australia, and the second one sits on a dedicated cluster with customer-managed encryption keys, for customers close to the defence sector.

Analytics, performance tuning, data validation and incident response all fall to one person.

The original idea: one engine instead of three

The decision that explains the result comes before any language model.

Lucius AI keeps the relational tender catalogue, the document metadata, the audit logs and the vector embeddings inside a single managed database, AlloyDB for PostgreSQL. The current playbook for an AI startup calls instead for three distinct pieces: a relational database, a vector database and a log store.

Three pieces mean three contracts, three backup plans, three ways to query the data and three surfaces to patch. For a headcount of one, that bill becomes the real cost of the product. Consolidation shifts maintenance from the person to the managed service.

Here lies the first transferable lesson: the advantage comes from the design of the data, ahead of the intelligence applied on top of it.

From 1.14 seconds to 24 milliseconds

The number that sticks concerns semantic search. By moving the vector index onto ScaNN, the latency of a representative production query dropped from 1.14 seconds to 24 milliseconds, a factor of 47, according to the technical write-up published by Google Cloud on 18 September 2026^[1].

The jump changes the nature of the product. Above a second the user feels the wait and abandons exploratory search; below 50 milliseconds that same search becomes a gesture you repeat ten times in a row.

For someone assessing a tender, that difference is worth hours of work. Screening moves from a cautious consultation to a rapid comparison across dozens of opportunities.

The independent outlet ITBrief Asia covered the migration and the shortened search times in an account outside the vendor's own channel^[2], useful for anyone who demands a second check.

The agent that administers the database

The second front concerns day-to-day administration.

Lucius AI connects an AI agent to AlloyDB through the Model Context Protocol, the standard that exposes tools and data to a model in a controlled way. The agent analyses queries, verifies data freshness and reconstructs incidents, within tight least-privilege permissions.

The permissions detail deserves attention. An agent with full access to a production database becomes a source of risk; an agent with a narrow perimeter stays a useful collaborator. The difference runs through configuration, ahead of the power of the model.

The practical result: the duties that occupy a database administrator in a normal company end up in the hands of an agent supervised by one person. This is the part of the case a chief technology officer can copy this week.

The point of friction: one number, one query

The story carries a stated limit, and the limit makes it useful.

The factor of 47 measures a representative production query, described as such by the source. The figure covers a sample, and a full workload mixes nightly writes, analytical aggregations and concurrent searches with different latency profiles.

Anyone reading a headline with a multiplier often finds a system-wide average behind it. Here the measure stays specific, and the honesty of the perimeter is worth more than the number itself: a before and after on a metric with a clear denominator beats any «significant improvement».

A second deliberate brake: the agent's minimal permissions reduce its autonomy. That is a perimeter correction, decided up front, and it marks operational maturity.

The second region carries a cost too. A separate Australian cluster, with customer-managed keys, duplicates monitoring and updates; the compliance demanded by customers close to defence is worth that price.

Where the bar has moved

One question still stands, the one that brings many people to this story: how much revenue does a one-person company selling artificial intelligence make?

The public material answers with operational measures: 210,000 tenders in the catalogue, thirteen sources, two regions, 24 milliseconds per query. Revenue figures stay private, and stating them as an estimate would mean inventing them.

The bar that has moved concerns the scale one person can serve. A single operator covers public markets on five continents with a product that generates compliance matrices, bid recommendations and draft responses with a citation back to the original page.

For a board of directors the benchmark changes here. The marginal cost of a new geographic market trends towards the cost of a new data source to ingest, and that figure is small.

The playbook for those with few resources

The moves in this story come down to four points, reproducible on a modest budget.

• One managed engine for all the data: relational, vector, audit logs.
• One specialised index for semantic search, measured before and after.
• One agent connected to the database with least-privilege permissions.
• One dedicated region where customer compliance calls for it.

Every move answers the real constraint on a solo founder: time. Administration time grows with the number of systems, and consolidation compresses it at the root.

A head of product draws another lesson. Search latency is a product feature, in the way the speed of a search engine changes the behaviour of the people using it. Treating it as a technical detail costs conversions.

For a manager the easiest move to take home concerns the agent: giving a model read access to logs and query statistics produces diagnoses in minutes. The narrow perimeter makes the experiment safe even on a live system.

What you can take away from this story

The competitive advantage of Lucius AI lives in the design of the data, ahead of the model that drafts the bids. The decision to keep catalogue, logs and vectors in a single managed engine made everything else possible, agent included.

The second element concerns the method of measurement. A before and after on a defined query, published with the company name and the date, stays verifiable by anyone who reads it.

The open question applies to any organisation, with ten people or with ten thousand: how many separate databases are you maintaining for historical reasons, and how much of your team's time goes into maintenance? That tally, done once with real numbers, guides the next architectural choice better than any demo.