// services
Legacy PHP & Vue applications, stabilized and moving forward.
The previous developer left, bugs keep piling up, dependencies are years out of date and every deployment feels risky. The product still earns money — it has just become expensive and stressful to change.
I take responsibility for the codebase: find what is fragile, fix what is urgent, document how the system works and make releases routine again — without stopping the business or rewriting everything from scratch.
01 // fit
This service is for you if…
- the developer who built the system has left and nobody fully understands how it works;
- the project runs on old PHP or Vue 2 and upgrades keep being postponed;
- deployments are manual, rare and usually followed by a round of fixes;
- small changes take weeks because every edit breaks something elsewhere;
- there is no documentation, no tests and no clear picture of the risks;
- you need a long-term technical owner rather than a one-off fix.
02 // scope
Scope of work
- scope/01
Codebase and dependency audit
A written map of the system: modules, integrations, outdated packages, security risks and the places that break most often.
- scope/02
Critical fixes first
Bugs that cost you money or users are fixed first, each with a clear explanation of the cause.
- scope/03
Dependency and runtime upgrades
Planned upgrades of PHP, frameworks and frontend packages, including PHP 8 and Vue 2 → 3 migrations where they make sense.
- scope/04
Safe deployment
Docker-based environments and a CI/CD pipeline, so releases become repeatable and can be rolled back.
- scope/05
Documentation
Setup, architecture and deployment notes that the next developer — or your own team — can actually use.
- scope/06
Ongoing maintenance
A monthly retainer: monitoring, updates, small features and a person who knows the system.
03 // diagram
From unknown codebase to predictable development
This scan walks through what a typical stabilization changes. The red lines are how projects usually arrive; the green lines are where the work takes them.
unknown codebase
documented system
critical dependencies
predictable development
unstable deployment
stable production
04 // pipeline.yml
How the work goes
- ~1 wkaudit:codebase
Audit
Access, a read-through of the code and infrastructure, and a list of risks ranked by business impact.
→ written findings - ~1 wkplan:stabilization
Plan
What to fix now, what to upgrade later and what to leave alone. You see the estimate before the work starts.
→ prioritized roadmap - weeksfix:stabilize
Stabilization
Critical bugs, dependency upgrades and a deployment pipeline — in small steps you can review.
→ stable codebase - per releasedeploy:release
Release
Changes go out through CI/CD with a rollback path, not by copying files to the server.
→ repeatable releases - ongoingsupport:ongoing
Support
Monitoring, updates and new features from the person who now knows the system.
→ maintained product
05 // outcomes
What you can expect
- A system you understand, with its architecture, setup and deployment documented.
- Fewer production surprises, because the most fragile parts are fixed or isolated.
- Releases that are routine instead of risky.
- A realistic upgrade path for PHP, frameworks and Vue instead of a forced rewrite.
- One accountable technical owner for the product.
06 // stack
Technology involved
The exact stack depends on the project. These are the technologies I work with most often in maintenance work.
07 // evidence
Where I have done this before
I have been the technical owner of a production fintech platform since 2020, and I regularly work inside codebases I did not start.
- 6 years with one product client — continuous ownership since April 2020.
- 99.9% production uptime, kept by resolving incidents, removing recurring failure modes and hardening critical services.
- Manual releases replaced with CI/CD: linting, tests and zero-downtime deploys.
- At Right Information: API endpoints and SSR features in a Yii2 / Nuxt 3 monorepo while keeping compatibility with the legacy platform.
08 // faq
Questions clients ask first
Can you work with code someone else wrote?
Yes — most maintenance projects start that way. The first step is always an audit: I read the code, the infrastructure and the deployment process before changing anything, so decisions are based on what is actually there.
Do we have to rewrite the application?
Usually not. A rewrite is expensive and risky for a product that already works. I prefer to stabilize, upgrade step by step and replace only the parts that truly block you. If a rewrite is the better option, the audit will show it, with reasons.
Can you upgrade us from Vue 2 to Vue 3, or to a newer PHP version?
Yes. Upgrades are planned as a series of small, testable steps, so the product keeps working during the migration instead of freezing for months.
How is maintenance billed?
Ongoing support works as a monthly retainer, from $30/h. The audit and stabilization phase is estimated separately, once the audit has made the scope clear.
What do you need from us to start?
Access to the repository and hosting, plus a person who knows the business processes. If some access has been lost, recovering it becomes part of the audit.
Can you stay on the project long term?
Yes. Long-term product work is what I prefer — my current client relationship has lasted more than six years.
09 // related
Related services
- takeover.shWeb application takeoverYour web application lost its developer or team. I audit everything — code, servers, access, data, integrations — and take responsibility for it.Taking over a web application without an owner →
- nuxt.config.tsNuxt & Vue developmentSSR, SEO, performance, API integrations and complex interfaces — Vue and Nuxt applications built to run in production, not just in a demo.Nuxt & Vue development for production products →
git push --message
Tell me about the system nobody wants to touch.
Send a short description: stack, hosting, what breaks and what worries you most. I reply within one working day with questions or a first step.