Accountability
Who is accountable for your project
One named delivery lead owns your engagement from discovery through handover, and the technical decisions are made by the people writing the code. This page sets out who answers for what, what happens when the person you deal with is unavailable, and the limits of a firm our size. We publish the structure rather than a page of headshots.
- Clients
- 680+Served since the company was founded in 2014.
- Projects delivered
- 720+In construction, healthcare, fintech, logistics and retail operations.
- Countries
- 21+All contracted through one United States entity.
- Delivery lead per engagement
- 1The same named person from discovery to handover.
- Every week
- Your delivery lead is on the call with that week's release, the change log and what moved.
- Between calls
- contact@opencollartech.com and +1 516 373 0561, during US business hours. No ticket queue in front of them.
- If we disagree
- You contract with OpenCollar Technologies LLC, a United States company, so there is one entity to hold to the agreement.
- If we vanish
- You already hold the source, the data, the credentials and a written runbook. Another team can pick the system up.
Prefer to start in writing? Send the detail through the contact page or call +1 516 373 0561.
Ownership of decisions
Who owns the relationship and the technical decisions?
One named delivery lead owns the relationship: they scope the work, run the weekly call and stay on the engagement from discovery to handover. The technical decisions belong to the engineers writing the code, and they are recorded in your repository rather than relayed through an account manager who was not in the room.
- The relationship
A named delivery lead, agreed during discovery.
They run the weekly call, answer the scope questions, and stay on the engagement through handover. They do not change when a phase ends.
- The architecture
The engineers building the system.
The stack, the data model and the integration choices are made by the people who have to live with them, and written into your repository with the option that was rejected and the reason why.
- Scope and money
The US entity you signed with.
Change requests are priced before they are built, against the model agreed in discovery: fixed scope on milestones, a dedicated team, staff augmentation, or managed support.
- When something breaks
Whoever the contract says, in writing, before you sign.
Support cover and its hours are agreed and priced rather than implied. We would rather write down a limit than let you assume a round-the-clock desk we do not run.
The delivery practice behind this is written up under our software development approach, and the four commercial models are compared on how we price engagements.
Continuity
What happens if the person you deal with is unavailable?
Nothing about your project stops being visible to you. From the first week, the repository, the database and the cloud accounts are held in your company's name, so continuity does not depend on any one person being reachable. It depends on nothing important living only in someone's head, which is a thing you can verify rather than a thing you have to trust.
- Work lands in your repository, not on a laptop
- Every week's release is pushed to a repository held in your company's name. The current state of the build is something you can look at without asking us for it.
- Credentials sit in your accounts from the start
- Cloud, domain, database and deployment accounts are opened in your name. Access is granted to named individuals at the least privilege the task needs, logged while it is in use, and revoked at handover.
- Decisions are written down, not remembered
- Architecture choices, data model changes and the awkward details of an integration are recorded as they are made, so the reasoning survives the person who made it.
- A runbook and a recorded walkthrough exist before handover
- Handover is a deliverable of the last phase, not a favour at the end. The stack is deliberately ordinary so another team, including your own, can read it.
Structure
How is the team structured on a project?
A project has one delivery lead, the engineers actually building it, and a named owner on your side who can make decisions. That is the whole structure. Nobody is moved off your build mid-phase to cover another account, and there is no account-management layer sitting between you and the people writing the code.
Your named owner
One person on your side who can set priorities and sign off. Their decisions are the ones we cannot make for you.
Delivery lead
Single point of contact. Runs the weekly call, holds the scope and the sequence, and does not change between phases.
Engineers on the build
The people writing the code and choosing the data model. Named at the start of a phase and kept until it ends.
Held in your name the whole way through
Repository, database, cloud and domain accounts, the written runbook and the decision history. Not a handover package assembled at the end, but where the work lives from week one.
How a project team is composed and sized is set out on our team and staffing page.
The same standard, applied to us
What if we are the key-person risk?
We tell clients to stop running a business on one person's spreadsheet. The same test applies to this firm: if we disappeared tomorrow, you would still hold a running system and everything needed to keep it running. That is a design constraint from the first week of the build, not a courtesy at the end of it.
- Source code
- In a repository in your company's name, updated every week of the build. There is no escrow arrangement to trigger, because the code was never only ours.
- Data
- The database schema and its contents, exportable at any point. Your data is not used to train third-party AI models.
- Credentials
- Cloud, domain and deployment accounts opened in your name. We hold access while the work needs it, and it is revoked at handover.
- Documentation
- A written runbook, a recorded walkthrough and the decision history in the repository. Enough for a team that has never met us to keep the system running.
The access controls behind this are described in how we manage security, and a system we built and handed over in full is documented in the Construction Quotes case study.
Limits
What are the honest limits of a firm this size?
We are a small senior firm, not a body shop. That buys you decisions made by the people writing the code, and it costs you scale: we cannot put a large parallel team on your project next month, and we take a limited number of engagements at a time. If that is the wrong trade for your project, it is better to know now than in month four.
What it costs you
- Start dates are a real constraint. If the next slot is weeks out, that is the answer you get, rather than a team assembled to fill the gap.
- We do not staff by the dozen. Work that genuinely needs a large parallel team is work we will tell you to place elsewhere.
- Round-the-clock support is not the default. Cover is written into the contract and priced, not assumed.
- We say no to work outside what we can support, including stacks we would be learning on your budget.
What you get instead
- The person who scoped your project is the person on your weekly call.
- No account-management layer between you and the people writing the code.
- A working end-to-end path on your own data inside 30 days, then a release every week.
- Everything you would need to leave, from the first week: source, data, credentials and a runbook.
Before you sign
Questions about who is accountable
These come up on almost every first call, so they are answered here rather than saved for the meeting. If yours is not below, the answer is a phone call away rather than a form response.
Why does this page not list named executives?
Because we only publish people we can stand behind by name, and this page previously carried invented ones. We would rather show you the accountability structure than a page of titles attached to stock photography. The named delivery lead for your engagement is agreed during discovery, and you speak to them before the work starts.
Who signs off the architecture on my project?
The engineers building the system, in writing, with the rejected option and the reason recorded in your repository. Your delivery lead brings the decision to the weekly call in plain language, so you can overrule it before it is built rather than after.
What happens if my delivery lead leaves?
The work does not leave with them. Your repository, database and cloud accounts are in your company's name and updated every week, and architecture decisions are written down as they are made, so a handover is a conversation rather than an excavation.
Do you move people off a project part-way through?
No. You are told who is on your project and you keep them through the phase. We do not rotate engineers between accounts to cover a gap somewhere else.
Who do I call when something is wrong?
Call +1 516 373 0561 or email contact@opencollartech.com during US business hours. You contract with OpenCollar Technologies LLC, a United States company, so there is one entity accountable for the agreement.
What do we own if we stop working with you?
A running system. The source code, the database and its contents, the deployment configuration, a written runbook and a recorded walkthrough are handed over at the end of the build rather than held back as leverage. Nothing stops working if you stop paying us.
More answers sit on the general FAQ, and the wider story of the company is on the about page.
Next step
Talk to the person who would run your build
Thirty minutes, with the person who would scope and lead the work rather than a salesperson. Bring the process that is breaking and you will get a straight answer on whether it is worth building software for, including when it is not.
If you would rather read first: the company overview covers what we build and for whom, pricing sets out the four commercial models, and where to start helps if you are not yet sure what to scope.
Need a consultation?
Drop us a line - we're here 24/7 to answer your questions and discuss your project ideas.