When a build has stalled
Project Rescue
Projects stall for ordinary reasons. Scope grew without the plan changing, the person who understood it left, the budget ran out before the last twenty percent, priorities moved. None of that means the work is worthless — but it does mean someone needs to say plainly where things actually stand. That is what we do first.
How we pick it up
Establish what you own
Repositories, hosting, domains and DNS, app store listings, third-party accounts, design files. Working out what exists and who holds it is often the most valuable outcome of the first week — and it is worth doing regardless of who finishes the build.
Assess the code honestly
We get it running locally first; if that is not possible, that finding tells you more than any code review. Then the things that decide whether it can be safely changed: dependency versions and security posture, test coverage, how deployment works, and how far the build drifted from what was specified.
Say whether it is worth finishing
A rebuild is the most expensive recommendation available and it is right less often than it gets proposed. Plenty of stalled projects are closer to done than they feel, and the failure was sequencing or decision-making rather than code. We will tell you when finishing is the better spend — including when that means you keep your current team.
Stabilise before improving
Where we do take it on, the first goal is a system that can be changed without fear: a working environment, a deploy path, tests around whatever we are about to touch. Only then does new work start. Adding features to something nobody can safely deploy is how projects stall a second time.
Leave you able to walk away
Code in repositories you own, documented setup, and a team that could hand over. We would rather be kept because the work is good than because leaving is painful — and a project that just went through a difficult handover deserves that guarantee more than most.
The proof
Work we have shipped, not a capability deck.
- Customer Owned Banking AssociationA website and member portal inherited from a previous agency that were not meeting anyone’s needs — members could not find information and the admin team could not maintain it. Reviewed, rebuilt and still supported.Read the case study
- Aelia Duty FreeAn Adobe Commerce platform with slow issue resolution and unaddressed bugs under a previous support arrangement. Stabilised first, then improved — multi-currency, multi-location, and unforgiving tax rules.Read the case study
Common questions
Will you just tell us to rebuild everything?
No, and we would rather not. A rebuild is the most expensive recommendation available and it is right less often than agencies pitching one suggest. Plenty of stalled projects are closer to finished than they feel — the code is sound and what failed was sequencing, decision-making or scope. We give you a written assessment of what is worth keeping before anyone talks about starting again.
What if we do not have access to the code or hosting?
Common, and usually recoverable. We help you work out what exists and who holds it — repositories, hosting, domains, DNS, app store listings, third-party accounts — and what you are contractually entitled to. Establishing what you actually own is often the single most valuable outcome of the first week, whoever ends up doing the work.
Can you work alongside our current developer or agency?
Yes, and it is frequently the better outcome. Not every stalled project needs a change of supplier; some need extra capacity, a second opinion on architecture, or someone to take one workstream off a stretched team. We are equally willing to hand back a stabilised project as to keep running it.
How do you assess an inherited codebase?
We get it running locally first — if that is not possible, that finding matters more than any code review. Then we look at the things that determine whether it can be safely changed: dependency versions and security posture, test coverage, how deployment works, where the data lives, and how far the build has diverged from what was specified. You get a plain-language assessment with the risks named, not a document arguing for a rebuild.
How quickly can you tell us where we stand?
For most projects, a short assessment gives you a defensible answer in days rather than weeks — what state it is in, what it would take to finish, and whether continuing is the right call. That is deliberately a small, self-contained piece of work, because you should be able to find out where you stand without committing to a build.
Do you work with clients outside Sydney?
Our head office is in Sydney and we work with clients across Australia — Melbourne, Brisbane, Perth, Adelaide and regional NSW included. Delivery has been remote-first for years, so a project runs the same way whether you are ten minutes away or in another state: scheduled calls, a shared board you can see at any time, and one named point of contact. We are happy to meet in person in Sydney.
Engagement models
How we work
Four straightforward ways to engage us. Pick the one that fits, or mix them as your needs change.
Staff Augmentation
Add experienced Shakewell developers, designers or specialists directly to your own team. Engagements typically run three to twelve months, but can be as short or long as you need — you get the skills without the commitment and cost of hiring full-time.
About staff augmentationFixed-Scope Projects
Have a defined outcome in mind? We scope it, price it and deliver it as a project — a clear timeline, agreed milestones and a single point of accountability from kickoff to handover.
Embedded Delivery Teams
For larger or longer-running work, a cross-functional Shakewell team — development, design and delivery management — plugs in as your delivery arm, working to your priorities and your reporting cadence.
Support & Maintenance
Already live? We keep websites, stores and apps secure, updated and performing through ongoing retainers — business-hours support as standard, with 24/7 coverage available for critical issues.
About support & maintenance