can you work on an existing codebase?
yes. we start with a short review (what it does, what shape it's in, what's risky) and give you a written assessment before we change anything. sometimes the honest answer is that a rewrite costs less than the repairs.
most of the work that comes to us isn't greenfield. it's the site the last agency walked away from, or an app whose original developer has moved on, or a system that works and nobody dares touch. that's normal, and it doesn't mean a rewrite by default.
the review comes first
before we change a line, we read the code, the infrastructure and the history. the written assessment you get covers three things:
- what it does: the features that exist, as opposed to the ones people believe exist.
- what shape it's in: dependencies near end-of-life, missing tests, hosting nobody can log into, credentials in the git history.
- what's risky: the parts that will break next, and the holes we'd expect a security tester to find.
you can act on that document with or without us. if the honest answer is that a rewrite costs less than the repairs, we say so in writing, with the reasoning, and you decide.
three ways it usually goes from there
- rescue and adoption. the builder is gone, so we document the system, stabilise it, and take it on.
- alongside your developers. we take the parts they don't cover, usually security or infrastructure, and agree in writing who owns what.
- security only. you keep your team and point us at the app for a review. that work stands alone; see security on apps we didn't build.
send us the repository link, or a login, and tell us what's worrying you. links help more than a long description.