Technical BA outsourcing · Bucharest · working with teams in the UK, EU and US
Hire a technical business analyst who can read the API contract.
We place a senior Technical Business Analyst, Technical Product Owner or delivery-focused Scrum Master inside an enterprise delivery team — most often in banking, capital markets, fintech, insurance and international institutions. We work in English and Romanian, from Bucharest.
A standard Bucharest working day overlaps London by about seven hours and US Eastern by two.
Where the sprint actually goes
Nobody writes down what happens when the signature provider times out.
A ticket says the customer should be able to sign the agreement digitally. Nobody disagrees. It goes into the sprint. Three weeks later, in UAT, someone asks what happens when the signature provider returns a timeout after the customer has accepted the terms but before the signed document comes back. Nobody decided that case, which is why nobody built it. Answering it now needs the product owner, the integration team, whoever owns the legal position, and someone who has actually read the provider's retry semantics.
By then you have paid for that story twice: once when the engineer built the path everyone agreed on, and again when they rebuild it around an answer that was available in refinement for the cost of one question. In the status report it appears as "bounced from UAT". In the retro it appears as "requirements". Nobody has done anything wrong, and the release date has still moved.
In a regulated programme it compounds a second time. The auditor does not ask whether the code works. They ask which requirement the change was made against, who approved it, and what test proved it. If that trail was never written as the work went through, someone spends the week before the review reconstructing it from Jira comments and Teams threads, and the answer they produce is a reconstruction, which is what an auditor is trained to notice.
That end of delivery is what we work at. What your engineers get is a specification they can build from without opening a follow-up conversation, and what your auditor gets is the trail that shows which requirement it came from.
Most BAs document. The question worth asking is whether your engineers can build from what yours hand over without asking a question. If they can, you don't need us.
What we supply
Take the role your team is actually missing.
These are separate jobs that get merged in most org charts, which is why teams keep hiring the wrong one. On a single squad, one person frequently covers the first two; we quote that as one role, not two.
Technical Business Analyst
Elicitation, the specification, acceptance criteria, integration and data-flow definition, and the traceability record.
Work items an engineer can start on the day they pull them.
Your refinement sessions keep ending with "we'll come back to that", or your engineers are sitting in meetings to establish what a ticket meant.
Technical Product Owner / Proxy Product Owner
The backlog, the order it is in, and the sign-off. Sits in the PO seat when the real business owner is a director who cannot make three ceremonies a week.
An ordered backlog with a stated reason for the order, and decisions at the speed the team needs them rather than the speed the steering committee meets.
The team is blocked waiting for a decision more often than waiting for a specification.
Delivery-focused Scrum Master
Cadence, the impediment list, and the forecast.
Ceremonies that finish, and a status you can repeat to a steering committee without softening it first.
Your ceremonies run on time and your dates still move.
We do not supply generalist project managers, delivery managers who don't write requirements, or a "BA" who is really a junior taking minutes. If that is what the seat needs, a volume supplier will fill it faster and cheaper than we will.
The artifact
What one of our tickets actually contains.
This is the part that is impossible to evaluate from a CV, so here is the anatomy. Every work item we hand an engineer carries:
- The requirement it came from, by ID, and the name of the person who asked for it.
- Acceptance criteria written as conditions a tester can pass or fail — including the ones nobody enjoys writing. The timeout. The partial failure. The duplicate submission. The record that already exists.
- The integration contract: endpoint, method, request and response shape, the error codes the other side actually returns, and what we do for each one. Where the other side is a third party, the version of their documentation we read and the day we read it, because that document will change and someone will need to know which version the behaviour was specified against.
- Field-level mapping wherever data crosses a system boundary, including what happens to a field that is mandatory on one side and optional on the other.
- A process model where the flow touches more than two systems or more than one department. BPMN, because it survives being handed to someone who was not in the room.
- The non-functional constraints that apply to this item specifically, rather than a page of them at the front of a document nobody opens. Response time, retention, who is permitted to see the record.
- The open questions, listed, each with the name of the person who owes the answer and the day we asked. An open question that is visible is a schedule risk. An open question that is implicit is a defect in six weeks.
And across the engagement, one line you can follow
Requirement → the change that implemented it → the test result → the name that approved it. Assembled as the work goes through, not reconstructed before a review. If your compliance function has ever asked for that trail after the fact, you already know what it costs to build late.
If you are the engineer, not the buyer
What the analyst will ask you for: the constraints you already know about, a read on whether an integration contract is realistic, and a decision when two requirements conflict. What they will not ask for is that you attend more ceremonies than you already do, or re-explain the system every sprint. Refinement plus one working conversation a week is the normal shape. When you disagree with a spec, the disagreement goes into the work item with your name on it, and the requirement either changes or it does not — either way you can see who decided and when.
What we don't produce
A forty-page functional specification document that is accurate on the day it is signed and wrong by the third sprint. The backlog is the artifact. Documents exist where a document is genuinely the deliverable — an integration contract, a process model, a handover pack — and not as evidence that analysis happened.
None of this is exotic. It is the standard that holds inside a bank because it has to. Most delivery teams already know what it looks like; what they are missing is somebody whose entire job is producing it while everyone else builds.
Track record
Where this work has been done.
Institutions where this Technical BA work was delivered
Most of these were delivered as a subcontractor under a prime: NTT DATA, Qualitance/ALTEN, Investigo/Definia and E-Resourcing UK. That is the route most enterprises use to bring in a specialist without opening a new supplier process, and we name the primes because procurement asks, and because it answers the "you're not on our approved list" question before anyone has to raise it.
Under Theta One Digital, since 2022
Universal Music Group (UK)
Jul 2025 – presentTechnical Business Analyst (contract)
Decommissioning a legacy rights-management system and migrating onto a modern stack. Business, legal and operational requirements written as technical specifications, plus the integration requirements and data flows between the systems on both sides of the migration.
Raiffeisen Bank Romania
Jul 2023 – Oct 2025Business Systems Analyst · Lead BA · Proxy Product Owner (contract)
Lending and insurance flows for existing customers, integrating the national tax authority, the credit bureau, a qualified digital-signature provider and an insurance carrier. Also a tablet advisory tool that replaced a paper process in branches.
UNFCCC (Germany)
Oct 2023 – Jun 2024IT Business Analyst · Proxy Product Owner (contract)
A carbon-accounting portal supporting Article 6 of the Paris Agreement. Regulatory requirements turned into backlog items and workflows, with stakeholder alignment across multiple countries.
LSEG (USA)
Apr 2023 – Dec 2023IT Business Analyst & Scrum Master (contract)
A collaboration platform letting analysts work together on real-time market data. User stories, functional and technical specifications, and the integration and non-functional constraints agreed with the engineering teams.
Finstro (Australia)
Aug 2022 – Mar 2023Solutions Designer · Technical Business Analyst (contract)
Enhancements to a digital lending platform across web and mobile, including SOAP-based integrations. Technical solutions designed with the solution architect, and API contracts defined for both clients.
Before Theta One, in permanent roles
ING Hubs Romania
Mar 2020 – Aug 2022Senior IT Business Analyst
Data governance and data integration for enterprise data platforms — a data lake and warehouse programme, with UAT support for the analytics, reporting and data-quality work built on top of it.
Alior Bank
Nov 2018 – Mar 2020IT Business Analyst
Fully digital customer onboarding and online lending across mobile and web, alongside the PSD2 and AML regulatory implementations.
DCA Ventures
Oct 2016 – Oct 2018Product Owner · Business Analyst
Product backlogs for EDI and marketing-automation platforms, both internal and client-facing. Where the practice starts, and why business analysis here dates to 2016 rather than to the firm.
We don't publish client case studies, named outcomes or quotes, because we didn't ask permission to and we are not going to write them from memory. On a call we will walk through any engagement above at whatever level of detail the NDA allows.
The dated recordWho shows up
The person who scopes the work is the person who does it.
Theodor Istratescu
Founder · Technical Business Analyst and Product Owner
Theodor has run Theta One Digital since 2022 and still does the analysis. Before that, nearly four years inside banks: data governance and data integration at ING Hubs Romania, Mar 2020 – Aug 2022, and digital onboarding, online lending, PSD2 and AML at Alior Bank, Nov 2018 – Mar 2020. Since founding the firm, contracting engagements across capital markets, UN climate finance, retail banking, lending and music rights, several running in parallel, all disclosed to each client and all non-competing.
He has sat in the proxy PO seat on a regulatory programme with stakeholders across several countries, run the lead-BA role over other analysts inside a bank, and held the technical interviews that bank used to hire its Technical BAs. That last one matters here more than it looks: the bar he screens candidates against is the bar a bank set.
Theta One is one senior practitioner. When you contract us you are contracting a named individual, not a logo with a rotation behind it. If your programme needs a second analyst next quarter, ask on the first call and you get a straight answer about whether that is possible and when.
How it starts
The first thirty days, in order.
Day 0 — the scoping call
Thirty minutes. We ask which squad is blocked, what is actually blocking it, who writes the requirements today, what tooling you run, what your definition of done says, and whether there is a prime or a preferred supplier route we should come in through. What you get back, whether or not you hire us, is a short written note saying where we think your requirements process is leaking and what we would fix first.
Days 1–5 — the person and the rate
You get the CV and a call with the person who would be embedded, before anything is signed. There is no shortlist because there is no bench: you are hiring a named individual, and the rate is in writing before the call rather than after it.
Contracting
Directly with Theta One Digiplex S.R.L., or as a subcontractor under a prime you already have on your supplier list. We sign your NDA and your MSA rather than asking you to review ours.
Week 1 — access, and reading
Your tools, not ours: your Jira or Azure DevOps, your Confluence, your repositories where the role needs read access, your ceremonies, your definition of done. The first week is spent reading — the last three releases, the open defect list, the last two UAT cycles, and whatever the team names when you ask which part of the system they dread. That week is what stops the first three sprints going on questions the team already answered for somebody else last year.
Weeks 2–4 — first output
By the end of week two you should be seeing refined work items. By the end of week four you should be able to see the difference in refinement itself: fewer open questions carried into planning, fewer stories coming back from engineering for clarification, fewer decisions deferred to whoever is on leave. If you cannot see it, say so at the four-week checkpoint. That is what the checkpoint is for, and it is a much cheaper conversation than the one at renewal.
Steady state
In your ceremonies, on your cadence, with a short written status each week saying what moved, what is blocked and who owes the answer. Escalation goes to a named person who is on the delivery, not to a salesperson. Once a month we review what has changed in the delivery rather than reviewing the relationship.
Your other options
What you're comparing this against.
You have four or five other options and most of them are reasonable. Here is where each one beats us, so you can tell when to use it instead.
A big consultancy.
Better than us when you need a hundred people, a global master agreement already in place, and a counterparty large enough to carry programme risk on paper. Worse when business analysis is a line item in their catalogue rather than the thing they are for. The person who presents in the pitch is rarely the person on your standup, the rate you agreed is usually a blended rate that buys whoever is available, and "senior" is a grade in their internal ladder, not a description of what the person has done.
A generic staff-augmentation supplier.
Better than us when you need volume quickly across many roles and the requirement is genuinely a seat to fill. Worse when the role is technical analysis. You get someone who takes accurate minutes and writes down what was said, which is a real skill and not the same skill as deciding what the system does when the third party returns a 409.
Hiring in-house.
Often the right answer, and we will say so on the call if it is. A permanent product with a permanent backlog should have a permanent analyst. The problem is the calendar: three to six months to fill for a genuinely technical BA, longer in a regulated market where the shortlist is short, and your squad is blocked now. Use us to unblock the squad and keep the requisition open.
A freelance BA from a marketplace.
Better than us when the scope is short, bounded, and nobody is going to audit it. Worse when continuity matters, when one person has to hold the traceability record across six months and a reorganisation, or when you need a second analyst at four weeks' notice and there is no one to ask.
Doing nothing.
Genuinely reasonable if the rework is not costing you a release. Less reasonable if you can already name the two stories that are going to come out of UAT this sprint.
"We already have BAs."
Then the question is narrower than it sounds. Sit in one refinement session and count the items that leave the room with an open question still attached to them. If that number is close to zero, you do not have a problem we can solve and you should not buy anything. If it is not close to zero, adding one analyst who works at the technical end usually costs less than the sprint you are about to spend finding out.
"We already have a supplier."
That is usually the easier route, not the harder one. We have been the subcontractor under someone else's prime on most of the engagements listed above. If you have a contract vehicle you would rather not reopen, ask us before you start a new vendor-onboarding process — coming in under your existing prime is frequently weeks faster and it costs you no supplier-list slot.
The smallest sensible first step
One Technical BA, one squad, one quarter. Not a programme, not a four-person pod, not a discovery phase that produces a deck. If it works you extend it and we talk about the second role. If it does not, you stop.
And if you stop
What you keep, in every case: every specification written, the backlog in the state it is in, the traceability record, the process models, and a handover pack that names every open question, every decision made and who made it, and where each integration got to. There is no exit fee, and nothing we produce for you lives in a tool you don't own — we work in your systems, so there is nothing to extract.
Scope limits
What we don't do.
We don't staff engineering teams.
If you need eight developers, we are the wrong call, and you will hear that on the first one rather than after we have tried to make it fit.
We aren't a five-thousand-person SI and won't behave like one.
We staff the analysis layer of large programmes. We don't bid the programme.
We don't sell juniors on a senior rate card.
There is one senior practitioner here. When he is not available we say so, rather than sending somebody else's CV with our name on it.
We don't take documentation-only roles.
If there is nobody on your side who can sign off a decision, we can produce a very good document and nothing will change. That is a governance problem and hiring an analyst won't fix it.
We don't sell discovery to warm up an account.
A paid requirements audit is on the table when the problem genuinely isn't understood yet. It is not a default first phase.
We don't take work where the AI question is unresolved.
If your policy restricts AI-assisted work, tell us at scoping and we staff accordingly. If you want the pipeline running behind the analysis, that is Etheria, it is in Beta, and it is a separate conversation with separate governance.
Commercial shape
How this is bought.
A single embedded specialist, time and materials, at a day rate by role.
A multi-role squad on a monthly retainer, where a programme needs an analyst plus a proxy PO, or an analyst plus a delivery-focused Scrum Master, working to the same backlog.
A fixed-scope requirements audit or discovery, where the first genuinely useful thing is a written view of where the current process breaks.
That page exists so a procurement team can open a file without booking a call first. Nothing on it is gated and there is no form.
Two other things we do
If you need more than the analysis.
If you want the build as well.
Our own engineers, on the classic model: analysis, design, build, test, release. The line is live and it is being folded into Etheria. We say that here rather than at contract stage.
If you want the pipeline behind the analysis.
Etheria runs on the same rules: acceptance criteria written before code, a traceability record assembled as the work moves, and a named approver on every change. It hands approved work items to an agent that writes the code and opens a pull request, and a named human approves before anything moves. It is in Beta. If that is more risk than you want this year, take an analyst on a normal contract; the pipeline is opt-in and that is the point of it.
Questions procurement asks
Next step
Bring one blocked squad to the call.
Thirty minutes. Tell us which squad is stuck, who writes the requirements today, and what your definition of done actually says. You get a written view back of where the requirements process is leaking, whether or not you hire us.
No sales sequence, no gated PDF, no call from someone who won't be on the delivery.