Sutram

01

What a tender costs a firm

A government tender is published as a set of documents with a deadline and a format that admits no error. Firms that bid professionally spend most of their time on the work preceding the bid: identifying which tenders are relevant, reading the documentation, and tracking what has been submitted and what has been paid.

Sutram covers that entire cycle in one platform — discovery, the documents, the bid, and the payment that concludes it.

02

One codebase, several firms

Each client is a separate firm with its own branding, its own users and its own commercially sensitive bids. The straightforward approach is to run a copy of the application per client and then maintain five copies indefinitely.

Instead there is one codebase and one deployment, with separation enforced in the database rather than in the code that queries it. That distinction is the one worth being careful about: an access rule written into a handler is a rule that will be omitted from the next endpoint, and in this domain a leak between two clients is not a defect report but the end of a contract.

• Row-level isolation, so each client’s data is separated by the database rather than by remembering to filter.
• Role-based access control governing what each user within a firm may see and do.
• White-label branding per tenant, from a single deployment.

03

Surfacing only the relevant tenders

Tender listings arrive in volume, and almost none of a given day’s postings are relevant to any one firm. Keyword filtering is too coarse, because the language of a tender rarely matches the language a firm uses to describe itself.

A retrieval pipeline reads incoming listings and surfaces only those within each client’s own field, which reduces the queue to a length that will actually be reviewed.

04

Five years of records into a database

The clients arrived with five years of history in spreadsheets and scanned PDFs — a complete record of everything they had bid for, in a form nothing could query.

An OCR ingestion pipeline migrated all of it into PostgreSQL without the loss of a record. That is the whole requirement: a migration that is 99% correct is one a client cannot rely on, and they would be correct not to.

05

Response times suited to daily use

This is software that remains open throughout the working day, so response time determines whether it functions as a tool or an obstruction.

Average API response time was reduced by 70% through four measures: Redis caching for data that does not change between requests, indexes for queries reading more than they required, load balancing, and rewriting the queries that were slow by construction rather than by volume.

06

Operating it, not only building it

The VPS is mine to operate as well: SSL/TLS, versioned releases and centralised logging, managed through Coolify.

Automating the release path removed approximately 20 minutes from every deploy. The time saved matters less than what it enables — a deploy that is quick and uneventful is one worth performing to correct something minor, rather than deferring it.