Most of what a supplier says about communication is unfalsifiable. “Regular updates”, “close collaboration” and “we’ll keep you informed” don’t tell you when you’ll hear about a slipped date, and you only find out what they meant in week nine. This page is the specific version of our outsourced development process: who you talk to, what hours we’re awake, how long a blocking question sits before somebody answers it, and what we put in the contract rather than in an email.
Some of it is a trade-off rather than a selling point. Those parts are marked as such, because you’ll find them out anyway and it’s better that you find them out now.
The three things agencies ask about first.
IST, Monday to Friday
To answer a blocking question
A fixed-price way to start
This depends on the model, and it’s the difference people most often discover too late.
On project-based work your contact is the project manager who runs the build, not the engineers. That’s a genuine trade-off and worth weighing. A single owner keeps the thread in one place and means you’re not managing a team you don’t employ, but technical questions travel through somebody, and that’s the structure that strips nuance on the way in and softens bad news on the way out.
If you want your delivery lead in direct contact with named engineers, in your own channels, that’s the dedicated team model and we set it up that way from the start. Decide which you want before signing, because changing it later means changing the commercial arrangement too.
Our coverage window is 10:00 to 20:00 IST, Monday to Friday, with people staggered across it depending on the market they support. Nobody works the whole span. The 20:00 finish is what makes Europe straightforward rather than a compromise — two hours at our end buys two hours at yours.
| Your market | Typical local hours | Overlap with our window | Note |
|---|---|---|---|
| Israel | 09:00–18:00 | 8.5 hours | Sunday to Thursday week, so four shared days rather than five |
| Central Europe | 09:00–17:30 | 7.5 hours summer, 6.5 winter | The best overlap in Europe |
| UK | 09:00–17:30 | 6.5 hours summer, 5.5 winter | Your entire morning and part of the afternoon |
| Singapore | 09:00–18:00 | 5.5 hours | No daylight saving to plan around |
| Eastern Australia | 09:00–17:00 | 2.5 hours winter, 1.5 summer | The hard case. Enough for a standup and one decision |
| US East Coast | 09:00–17:00 | About 1 hour | Works on an early-morning Eastern call, then a full Indian day on the outcome |
| US West Coast | 09:00–17:00 | Effectively none | Would require somebody to work unsociable hours |
We publish the awkward rows because the useful ones aren’t worth much without them. Australia is a market we actively work in and it’s still our weakest overlap — closer to ninety minutes once Sydney moves to daylight saving in October. That’s workable with real asynchronous discipline and not workable on optimism. Daylight saving moves several of these rows, and the UK, EU, US, Israel and Australia don’t all switch on the same dates, so expect two or three weeks a year where the overlap you agreed is an hour shorter than you planned.
The cost of a distributed team isn’t the hours, it’s the waiting. A developer blocked at eleven in the morning who can’t get an answer until tomorrow loses most of a day, and that pattern repeated across a twelve-week build is where the reputation for offshore work being slow actually comes from.
Our answer is a few hours inside our working window. That isn’t a contractual service level and we won’t dress it up as one — it’s what happens, and it’s the number to hold us to. It’s worth agreeing the same thing in the other direction, because schedules slip on client approval latency at least as often, and the supplier usually gets blamed for the calendar.
The cadence should match the model, because they’re different jobs. Fixed-scope project work reports weekly or at milestones; daily notes on work you aren’t directing become noise nobody opens. A dedicated engineer working to your direction is the opposite — you’re making the decisions, so you need the day’s blockers before your day starts, and they can send you an end-of-day update directly.
Whichever it is, ask for four things rather than a summary: what moved, what’s blocked and on whom, what decision is needed and by when, and what gets picked up next. A handover that never names something you have to answer is a status report, and it’ll tell you about the blocker several days after you could have cleared it.
We work to an internal coding standard, and on PHP we follow PER-CS, the coding style published by the PHP Framework Interop Group. A standard is only worth anything if somebody enforces it, so the more useful question is who checks the work and who can send it back.
Where a team includes junior engineers, a senior developer reviews their work before it reaches the project manager. Both the senior developer or team lead and the project manager can reject work and return it. If you want every change reviewed by a second engineer regardless of who wrote it, say so at kickoff and we’ll set the engagement up that way — it’s a reasonable thing to ask for and a reasonable thing to write down.
Done means the functionality works and that both functional and automated testing have been completed. Documentation is produced where it sits inside the project scope, and it’s written after you’ve confirmed the functionality rather than alongside it, so that it describes what was actually built rather than what was planned. If you need documentation as a deliverable, put it in the scope, because it isn’t assumed.
We don’t hand over code or repository access at the start. Access follows the agreed milestones and payments, and the points at which you receive it are written into the contract before work begins.
This is the point on the page most likely to give an agency pause, so it’s worth being direct about it. It’s a commercial protection rather than a delivery one, it is negotiable, and it’s a fair thing to raise before you sign rather than after. What we won’t do is describe it vaguely and let you assume otherwise.
Intellectual property and code transfer to you in full on the terms in the contract, after payment rather than before. We’ll show you the clause before you sign it rather than describing it in an email.
Our confidentiality terms cover your client’s identity, not only yours. We won’t name you or your client in our own marketing without your permission, and that applies to case studies, this website and anything we say in a sales conversation with somebody else.
On paperwork, we’ll sign your NDA where it works alongside how we operate. Where it doesn’t, we have our own that you can use instead, and we’d rather tell you which clause is the problem than sign something we can’t honour.
Almost all work stays inside our own team. Where a piece of work needs a skill we don’t hold, or capacity we can’t free in time, we occasionally bring in a trusted specialist. When that happens the contract doesn’t change: Ablion remains the single point of accountability for delivery, and everyone who touches your project signs the same confidentiality terms, including those protecting your client’s identity. If you want our position on a particular engagement, ask and we’ll tell you.
Invisibility is a set of specific surfaces with a specific owner, not a promise to stay off client calls. How much of it we hold depends on whose infrastructure the project runs on, so here is the honest split.
| Surface | Who controls it | Note |
|---|---|---|
| Commit authors and email addresses | Us, where the code is in our repository | In your repository we commit under whatever identity you specify |
| Repository and organisation names | Us, where the code is in our repository | Yours where the work lives in your organisation |
| Staging domain and DNS | Us by default | Yours if you would rather provide them |
| Deployment and hosting accounts | Us where hosting is inside the scope | Yours where you host it |
| Monitoring and alerting | Us during development | Moved to you or your client at deployment |
| Project documentation | Us, written to hand over as yours | Where documentation sits inside the delivery scope |
Your project manager owns that list for the length of the engagement. The practical step is to agree at kickoff which side owns each surface, and to name anything not on the list before access is created rather than after. Most exposure happens where both parties assumed the other one had it, not because anyone was careless.
What you receive is set by the deliverables in the agreement rather than by a standard list, so read that clause before you sign it rather than relying on custom. In the normal case it is the repository, the deployment and setup instructions needed to stand the application up somewhere else, and the credentials that go with them.
If there is something specific you would want on the final day — environment configuration, a list of open issues, a walkthrough with the engineer who built it — name it while you are negotiating. It is a great deal easier to write into the scope at the start than to request at the end.
We accept a paid pilot before a full engagement and we think it’s a sensible way for an agency to start. A pilot is normally fixed price. Where the specification isn’t settled, or it changes materially partway through, we bill hourly instead, and we’ll tell you which of the two we think applies before starting rather than after.
Lead time from a signed agreement depends on the size of the work. Usually an engineer is on it within a few days, and within a few weeks for something larger.
Before any of that, the useful first conversation is a short one about whether the clock works for you at all, what you’ve sold, and what your client can’t be allowed to see.
Company registration detail, staff figures, turnover, rates, contract mechanics and termination terms are answered directly, with documents, rather than published here. We’ll identify the contracting entity, provide corporate and contractual records for review, explain the proposed commercial structure, and answer reasonable due-diligence questions about continuity and exit. Where confidentiality or data protection limits what we can share, we’ll tell you what the limit is and provide redacted evidence instead of a general assurance.
The reason is the same reason you’d appoint a white-label partner in the first place. A supplier that publishes its internal figures on a marketing page hasn’t thought carefully about confidentiality, and confidentiality is the product. Ask for any of it and you’ll get it, with evidence rather than assertion.
It depends on the model. On project work your contact is the project manager running the build. On a dedicated team your delivery lead talks to named engineers directly, in your own channels. Decide which you want before signing, because it changes how the engagement runs day to day.
10:00 to 20:00 IST, Monday to Friday, with people staggered across the window depending on the market they support. That gives a UK team five and a half to six and a half hours of overlap, Central Europe six and a half to seven and a half, Israel around eight and a half, Singapore five and a half, and eastern Australia one and a half to two and a half.
Within a few hours inside our working window. That’s what happens rather than a contractual service level, and we’d rather describe it accurately than promise something we’d have to defend. It’s worth agreeing a number in the other direction too, because approval latency on the client side slips schedules just as often.
Where a team includes junior engineers, a senior developer reviews the work before it reaches the project manager, and both the senior developer or team lead and the project manager can reject it. If you want review by a second engineer on every change regardless of author, ask for it at kickoff and we’ll set the engagement up that way.
Access follows the agreed milestones and payments, with the points written into the contract before work starts. It’s a commercial protection rather than a delivery one, it’s negotiable, and it’s a fair thing to raise before signing.
You do, in full, on the terms in the contract, transferring after payment. We’ll show you the clause before you sign it.
