The software we own, stated at its real stage.
Software TDACorp owns, built to sharpen the engineering rather than to be sold today. The services arm is meant to pay for it. Here is what is on the bench, and exactly how far along each piece is.
Why a product engineering company owns deeper software.
Most software is built on top of other people's software. That is a reasonable trade until the layer underneath stops fitting the problem, and then you are debugging someone else's assumptions with no way to change them. Owning that layer is what keeps the option open, on our own products and on a client's.
The route there is not investment, it is engineering work. Hard client problems pay for the build, and they are a better signal than a roadmap written in a room, because a problem somebody is willing to pay to solve is a problem that is real.
The sequence is deliberately unglamorous: services first, products after, and the site says which is which at every point rather than blurring the two into one confident paragraph.
One available service, three products in build, one planned.
The status beside each name is the whole point of this page. It is maintained as the real state changes, not as a launch approaches.
Available means you can engage it today. In development means it is being actively built and is not shippable. Planned means the design exists and the build has not started. Nothing here uses a fourth word.
Engineering and consulting
AvailableSystems work, security, full-stack builds
The one thing on this page you can actually engage today. Specialized systems engineering for companies that need real depth rather than a template, and the arm meant to pay for everything below it.
- Open for work now, on the terms set out under Services.
- Direct communication with the people building the thing, no account-manager layer.
The operating system
In developmentLinux-based, lean, transparent, secure by construction
An in-house Linux-based operating system for developers and organizations who want an environment tuned to how they work instead of a general-purpose system they spend their time fighting. This is the cornerstone of the roadmap, and it is in design and early development.
- Modular by construction: the parts you do not want are absent, not disabled.
- Transparent defaults, so what the machine is doing at boot is inspectable rather than folklore.
- Performance and security treated as build-time decisions, not as later hardening passes.
- No downloadable build exists yet. When there is one to run, this page will say so.
DocuLens
In developmentDocument intelligence with a human in the loop
Upload a document and it classifies the type, extracts the fields with a confidence score against each one, and routes anything it is unsure about to a person rather than guessing. Built for the case where an extraction error is expensive, which is most of the cases worth automating.
- Field-level confidence, so the review queue is the low-confidence extractions rather than everything.
- The human step is part of the design, not a fallback bolted on after the model disappointed someone.
- Not hosted yet. It will run at doculens.products.tdacorp.in, and this entry says Available on the day that URL answers.
QueryFlow
In developmentAsk a question in English, get the query and the chart
Connect a database, ask in plain language, and it generates the SQL against the real schema, runs it, and draws the result. The generated query is shown rather than hidden, because a number nobody can trace back to a query is not an answer.
- Schema-aware generation: it reads the actual tables rather than guessing column names.
- The SQL is visible and editable, so a wrong answer is debuggable instead of mysterious.
- Not hosted yet. It will run at queryflow.products.tdacorp.in, and this entry says Available on the day that URL answers.
AgentForge
PlannedMulti-agent workflows, built visually and run in production
A visual builder for multi-step agent workflows, with the execution engine underneath treated as the hard part: retries, approvals, and what happens when a step fails at three in the morning. Designed, and the design is the honest extent of it today.
- Approval and decision nodes are first-class, because an agent workflow nobody can interrupt is one nobody will authorise.
- The execution engine is the product; the canvas is how you address it.
- Planned, not started. It will run at agentforge.products.tdacorp.in.
The rules the product work runs on.
These are constraints we hold ourselves to while nobody is watching, which is the only time they matter.
- First principles before dependencies. A library is a decision, and a decision we cannot debug is a decision we do not take lightly.
- The layer underneath is ours. Where a product needs the systems layer to behave differently, we change the systems layer instead of working around it.
- Nothing ships as a product until it is one. An early build gets described at its real stage on this site, not renamed to a beta and put behind a signup form.
- The build gets narrated as it happens. Decisions, dead ends and rewrites go under Learn while they are still fresh enough to be useful.
- Client work informs the roadmap, it does not become the roadmap. A one-off need is a job, a repeated need is a product.
The order this gets built in.
Phases rather than dates. When a date is real it will appear here, and not one day before.
The marker sits on the phase the work is actually in today. Everything below it is ahead of us, not behind us.
- Done
The company is set up and the work is open
Incorporation and company setup are complete, the engineering arm is open for work, and the product architecture is decided. The foundations are in place and the build sequence below runs from here.
- Now
Operating system: design and early development
The systems layer is where the effort sits today. Architecture, the module model, and the early build. No release, no download, no date.
- Next
Developer platforms against a real systems layer
The platform work grows as the layer underneath firms up, so the integration is designed in rather than retrofitted onto whatever shipped first.
- Later
Cloud-native tooling, and one coherent stack
The tooling completes the picture: the operating system, the platforms and the infrastructure around them designed as one thing rather than three products that happen to share a logo.
The products are the depth. The services are the offer.
Owned software is where the engineering gets sharpened: the operating system work is why the infrastructure and security judgment on a client build is worth paying for. If you have a product to build, that is the conversation to start.