[{"data":1,"prerenderedAt":408},["ShallowReactive",2],{"footer-vacatures-en":3,"case-softwareplatform-overnemen-en-professionaliseren-en":4,"content-by-keys-useCases-en-ai-project-overnemen-van-andere-leverancier,developmentteam-loopt-vast-met-ai,prototype-naar-onderhoudbaar-softwareproduct":171},[],{"id":5,"title":6,"approach":7,"body":22,"build":29,"card":42,"connections":47,"cta":48,"dataExamples":47,"description":26,"extension":54,"facts":55,"featured":70,"guardrails":47,"hero":71,"integrations":47,"key":76,"meta":77,"navigation":78,"offers":79,"order":89,"path":90,"proof":91,"relations":104,"result":121,"seo":133,"situation":136,"stem":149,"summary":150,"usecases":151,"visuals":163,"__hash__":170},"cases_en\u002Fcases\u002Fsoftwareplatform-overnemen-en-professionaliseren.md","From maintenance mode to active development again",{"title":8,"steps":9},"How did we approach it?",[10,13,16,19],{"title":11,"text":12},"First understand the system","We mapped the architecture, active functionality, databases, parsers, integrations and infrastructure. Not on the assumption that everything had to be replaced, but to determine what was good and where change was really needed.\n",{"title":14,"text":15},"Organise feedback and monitoring","Among other things, we set up coverage measurement, error monitoring and an acceptance environment. This made it visible sooner what changes did, so problems no longer had to be discovered through users or manual checks.\n",{"title":17,"text":18},"Targeted refactoring and testing","We removed unused code, introduced more structure and conventions, and improved components as soon as we understood them well enough. At the same time, we systematically expanded the automated tests.\n",{"title":20,"text":21},"Then continue development","As the codebase became better known, tested and manageable, we could develop features again and carry out larger technical improvements without treating every change as a gamble.\n",{"type":23,"value":24,"toc":25},"minimark",[],{"title":26,"searchDepth":27,"depth":27,"links":28},"",2,[],{"title":30,"intro":31,"points":32},"What did we build?","The most important result was a professional technical foundation under an existing product. We made the backend more explicit, more testable and easier to manage without needlessly replacing working parts.\n",[33,36,39],{"title":34,"text":35},"A backend we actually understood","We examined and improved the code until it was clear which components were responsible for what. Old, duplicate or unclear implementations could then be removed or improved in a targeted way.\n",{"title":37,"text":38},"Tests as a safety net","Test coverage became part of the normal development workflow. The relevant backend code grew from around 10% coverage at the start to 92%, with tests on the parts where they actually added value.\n",{"title":40,"text":41},"Professional engineering around the code","Besides the code itself, we also improved the environment around it, including error monitoring, coverage tooling, acceptance, infrastructure and the technical management needed to responsibly keep developing a production platform.\n",{"tag":43,"title":44,"summary":45,"metric":46},"Software rescue","From maintenance mode back to active development","An existing software platform had become so difficult to change that regular development had almost ground to a halt. We brought the backend, tests, monitoring and development process back under control.","Test coverage from around 10% to 92%.",null,{"title":49,"body":50,"primaryCta":51,"secondaryCta":52,"local":53},"Software nobody dares to touch anymore?","Explain what is there, where development gets stuck and what you are trying to achieve. We look into the technology and quickly tell you what is sensible to keep, repair or rebuild.\n","Book a call","View offer","Senior AI and software engineering from Delft, for organisations in Delft, The Hague, Rotterdam and the surrounding area.\n","md",{"title":56,"items":57},"The case in brief",[58,61,64,67],{"label":59,"value":60},"Result","From maintenance mode to active development",{"label":62,"value":63},"Test coverage","From around 10% to 92%",{"label":65,"value":66},"Delivered","Refactoring, tests, monitoring and technical control",{"label":68,"value":69},"Follow-up","Years of further development on the same foundation",false,{"headline":72,"intro":73,"primaryCta":74,"secondaryCta":75},"Making a platform that could only be maintained ready for development again.","The software worked, but changing it was risky. The previous development partner no longer did regular development and only stepped in when something broke. We did not start by rebuilding everything. First we had to understand what was there, what was good and where the real technical blockers were.\n","See the result","Tell us about your problem","softwareplatform-overnemen-en-professionaliseren",{},true,{"eyebrow":80,"primary":81},"Matching offer",{"key":82,"title":83,"text":84,"price":85,"result":86,"duration":87,"nextStep":88},"vibe-code-rescue-audit","Vibe Code Rescue Audit","We examine what is there, where the real technical risks are and what should be kept, repaired or replaced.\n","€2,950 excl. VAT","Technical analysis with a concrete rescue plan","Fixed scope","Afterwards you know whether a Rescue Sprint or a larger approach is needed",1,"\u002Fcases\u002Fsoftwareplatform-overnemen-en-professionaliseren",{"title":92,"intro":93,"points":94},"Proof","The progress was not only visible in cleaner code. We could measure it and then prove it in practice for years by further expanding the platform. The original analysis also showed that not everything was bad. Parts of the infrastructure, scalability and performance were already in decent shape. That is why we chose targeted professionalisation instead of automatically rebuilding everything.\n",[95,98,101],{"title":96,"text":97},"10% → 92% line coverage","At the start, an important backend component had around 3,400 lines of code and barely 10% line coverage. In the end, the relevant backend code reached 92% test coverage.\n",{"title":99,"text":100},"From break-fix to years of new features","Before the takeover, the agreement was that the previous development partner would only intervene when something broke. After the professionalisation we developed the platform for years with new functionality and technical improvements.\n",{"title":102,"text":103},"Later even our own machine learning","One of the later developments was a self-trained model for recognising offers in PDF store flyers. A good example of how much technical room had opened up again after the takeover and professionalisation.\n",{"buyerTriggerKeys":105,"useCaseKeys":107,"offerKeys":111,"capabilityKeys":114},[106],"vastgelopen-met-ai",[108,109,110],"ai-project-overnemen-van-andere-leverancier","developmentteam-loopt-vast-met-ai","prototype-naar-onderhoudbaar-softwareproduct",[82,112,113],"rescue-sprint","build-integrate",[115,116,117,118,119,120],"software-engineering","backend-engineering","testing","monitoring","refactoring","machine-learning",{"title":122,"items":123},"What changed?",[124,127,130],{"title":125,"text":126},"From around 10% to 92% test coverage","The most important backend code started with about 10% line coverage. During the professionalisation we brought test coverage to 92%. Changes could therefore be verified much faster and with considerably more certainty.\n",{"title":128,"text":129},"New development got going again","The platform did not stay stuck in maintenance. In the years that followed we developed a lot of new functionality and made larger technical improvements on the same codebase.\n",{"title":131,"text":132},"The foundation became strong enough for new technology","The technical foundation became stable and understandable enough to keep innovating. Later, for example, we trained our own machine learning model to automatically recognise offers in PDFs of store flyers.\n",{"title":134,"description":135},"Taking over and professionalising an existing software platform | 9to5 software","Case: 9to5 software took over a stalled software platform, professionalised the backend and raised test coverage from around 10% to 92%. New functionality was built on it for years afterwards.\n",{"title":137,"intro":138,"points":139},"Where did it get stuck?","The platform consisted of several apps, web environments and an extensive backend. The existing software held a lot of value, but technical debt made new development increasingly difficult. Before changing anything, we therefore first systematically examined the existing code and architecture.\n",[140,143,146],{"title":141,"text":142},"New development had practically stopped","The previous development partner no longer did regular development. They only intervened when something actually broke. The platform ran, but technically it was hardly moving forward.\n",{"title":144,"text":145},"The backend was hard to understand","Functionality was spread over several Elixir apps within an umbrella structure. Names like old, new, v2 and v3 lived side by side, documentation was missing in important places, and different development styles and conventions made it hard to see which code was still leading.\n",{"title":147,"text":148},"Critical code was barely covered","In one important backend component we measured about 10% line coverage on around 3,400 lines of code at the start. Other components also had limited or virtually no test coverage. As a result, a change could silently break existing functionality.\n","cases\u002Fsoftwareplatform-overnemen-en-professionaliseren","An existing software platform had become so hard to change technically that the previous development partner only did maintenance. We took over the system, brought the backend under control and professionalised the code, tests, monitoring and development process. Test coverage grew from around 10% to 92%, and in the years that followed we were able to develop the platform extensively again.\n",{"title":152,"items":153},"Does this sound familiar?",[154,157,160],{"title":155,"text":156},"We have software nobody dares to touch anymore","Every change feels risky because tests, documentation or knowledge of the code are missing.\n",{"title":158,"text":159},"Our previous development partner is gone or cannot move forward","The system needs to be taken over without first spending months rebuilding everything.\n",{"title":161,"text":162},"Maintenance still works, but new development does not","The product runs, but technical debt makes new features increasingly expensive and unpredictable.\n",{"hero":164,"situation":165,"approach":166,"build":167,"proof":168,"teaser":169},"sq-tangle-knot","\u002Fmedia\u002Fscreenshots\u002Fsoftware-rescue-situation.webp","ls-rescue-repair","\u002Fmedia\u002Fscreenshots\u002Fsoftware-rescue-build.webp","\u002Fmedia\u002Fscreenshots\u002Fsoftware-rescue-coverage.webp","\u002Fmedia\u002Fscreenshots\u002Fsoftware-rescue-teaser.webp","oNFFM_t42kZnbXMyeVr9Ih81Bzf6OVtCfy_h4YhRVtc",[172,250,328],{"id":173,"title":174,"body":175,"description":26,"desiredOutcome":179,"extension":54,"hero":191,"key":108,"meta":193,"navigation":78,"path":194,"problem":195,"proof":207,"recognition":219,"recommendedApproach":234,"relations":236,"seo":242,"stem":245,"summary":246,"visuals":247,"__hash__":249},"useCases_en\u002Fuse-cases\u002Fai-project-overnemen-van-andere-leverancier.md","Another vendor left something behind that we can't properly continue with",{"type":23,"value":176,"toc":177},[],{"title":26,"searchDepth":27,"depth":27,"links":178},[],{"intro":180,"items":181},"The system should be understandable to more people than just the party that built it.\n",[182,185,188],{"title":183,"text":184},"Technical grip regained","Architecture, deployment, data and external dependencies are clear again.\n",{"title":186,"text":187},"Risks are prioritised","You know which parts are fine and where work is needed first.\n",{"title":189,"text":190},"The project becomes transferable again","Your team or a new vendor can continue development responsibly.\n",{"intro":192},"The original developer is gone, the documentation is thin and every change starts with the question: does anyone know how this works? We can step in, reconstruct what is there and get you moving again.\n",{},"\u002Fuse-cases\u002Fai-project-overnemen-van-andere-leverancier",{"intro":196,"causes":197},"Taking over software is more than getting access to the Git repository.\n",[198,201,204],{"title":199,"text":200},"Knowledge sat with people, not in the system","Architecture and operational choices were never documented well enough.\n",{"title":202,"text":203},"Ownership is scattered","Code, infrastructure, accounts and data may sit with different parties.\n",{"title":205,"text":206},"The technical quality is still unknown","You don't know what merely feels unfamiliar and what is an actual risk.\n",{"intro":208,"points":209},"Stepping into existing software is part of senior engineering. You don't need to have built the system yourself to bring structure and grip back into it.\n",[210,213,216],{"title":211,"text":212},"We start with what exists","A different vendor is no reason to rebuild right away.\n",{"title":214,"text":215},"Code and operations","Deployment, accounts and integrations belong to the handover just as much.\n",{"title":217,"text":218},"Avoiding a new dependency","The software should be easier to hand over after our work, not harder.\n",{"intro":220,"signals":221},"A handover can be complete on paper while the most important knowledge is still missing.\n",[222,225,228,231],{"title":223,"text":224},"The repository is there, but context is missing","Important choices were never recorded anywhere.\n",{"title":226,"text":227},"Deployment is a black box","Nobody knows exactly which steps, accounts or infrastructure are needed.\n",{"title":229,"text":230},"External services are scattered","Credentials, providers and admin accounts sit with different people or parties.\n",{"title":232,"text":233},"Every change first requires research","Engineers have to reconstruct again and again how functionality fits together.\n",{"intro":235},"With a Vibe Code Rescue Audit we first reconstruct what is there and what is still missing. Specific technical blockers can then be tackled in a Rescue Sprint.\n",{"buyerTriggerKeys":237,"primaryOfferKey":82,"offerKeys":238,"caseKeys":239,"relatedUseCaseKeys":240},[106],[82,112],[],[241,110],"technische-second-opinion-ai",{"title":243,"description":244},"Take over an AI project from another vendor | 9to5 software","Stuck with software from a previous vendor? 9to5 reconstructs architecture and code, maps the risks and makes the project transferable again.\n","use-cases\u002Fai-project-overnemen-van-andere-leverancier","The software exists, but knowledge, documentation or technical grip is missing after another party left.\n",{"hero":164,"problem":248,"proof":166},"sq-connect-nodes","rxzyg-E8-PHje_fvva9yRDf64IMLaDvF_b0hlCG-M4Y",{"id":251,"title":252,"body":253,"description":26,"desiredOutcome":257,"extension":54,"hero":269,"key":109,"meta":271,"navigation":78,"path":272,"problem":273,"proof":285,"recognition":297,"recommendedApproach":312,"relations":314,"seo":320,"stem":323,"summary":324,"visuals":325,"__hash__":327},"useCases_en\u002Fuse-cases\u002Fdevelopmentteam-loopt-vast-met-ai.md","Our own development team is technically stuck",{"type":23,"value":254,"toc":255},[],{"title":26,"searchDepth":27,"depth":27,"links":256},[],{"intro":258,"items":259},"You don't want to replace the existing team, but to remove the technical blocker so the team can move forward on its own again.\n",[260,263,266],{"title":261,"text":262},"The hard part gets solved","Senior engineers tackle exactly the part the team is stuck on.\n",{"title":264,"text":265},"Knowledge stays in-house","Your engineers understand the solution and the most important trade-offs.\n",{"title":267,"text":268},"No extra dependency","After the rescue, 9to5 doesn't need to remain part of the team permanently.\n",{"intro":270},"Sometimes you don't need an extra team. You need someone who quickly gets to the bottom of one complicated technical problem, solves it together with your engineers and then leaves again. That is where we like to step in.\n",{},"\u002Fuse-cases\u002Fdevelopmentteam-loopt-vast-met-ai",{"intro":274,"causes":275},"AI projects combine several disciplines. Even a strong development team doesn't need to have immediate experience with every specialist part.\n",[276,279,282],{"title":277,"text":278},"The problem is multidisciplinary","Software architecture, models, data, integrations and observability all touch.\n",{"title":280,"text":281},"Experience with this specific failure mode is missing","Some problems are solved much faster when you've seen them before.\n",{"title":283,"text":284},"Internal experimenting gets expensive","After several failed routes, searching further costs more than temporary specialist help.\n",{"intro":286,"points":287},"This is how we want to work: bring in senior engineering where it gets hard and leave again once your own team can carry on.\n",[288,291,294],{"title":289,"text":290},"Engineers work with engineers","No advisory layer between the problem and the people who actually change the code.\n",{"title":292,"text":293},"The existing stack remains the starting point","We don't bring in a new tool or architecture by default.\n",{"title":295,"text":296},"Handover from the start","The solution doesn't become needlessly dependent on whoever built it.\n",{"intro":298,"signals":299},"A good software team doesn't automatically have all the experience with agents, LLMs, agentic coding (Claude Code, Codex) and production AI in-house.\n",[300,303,306,309],{"title":301,"text":302},"The team keeps returning to the same problem","Different solutions are tried without a structural breakthrough.\n",{"title":304,"text":305},"AI-specific choices remain uncertain","Model behaviour, evals, agent architecture or retrieval call for different experience.\n",{"title":307,"text":308},"An integration turns out much harder than expected","The problem sits on the boundary between existing software and the new AI functionality.\n",{"title":310,"text":311},"A senior hire is disproportionate","You need specific expertise now, but not necessarily permanently.\n",{"intro":313},"If the problem is sharp enough, we step in right next to the team with a Rescue Sprint. We work in the existing codebase, solve the blocker and transfer the relevant knowledge along the way. If the root cause is unclear, we start with an audit first.\n",{"buyerTriggerKeys":315,"primaryOfferKey":112,"offerKeys":316,"caseKeys":317,"relatedUseCaseKeys":318},[106],[112,82],[],[241,319],"ai-koppelen-aan-bestaande-systemen",{"title":321,"description":322},"Development team stuck with AI | 9to5 software","Development team stuck with AI agents or agentic coding (Claude Code, Codex)? 9to5 steps in temporarily, solves the technical problem and hands it back over.\n","use-cases\u002Fdevelopmentteam-loopt-vast-met-ai","The team builds software just fine, but lacks the specific senior experience to solve a tricky AI problem properly.\n",{"hero":164,"problem":326,"proof":166},"sq-orient-options","G-CaoUkXnekooXGZnXL-EzJ47Frx3e9u27FGNRjxr3k",{"id":329,"title":330,"body":331,"description":26,"desiredOutcome":335,"extension":54,"hero":347,"key":110,"meta":349,"navigation":78,"path":350,"problem":351,"proof":363,"recognition":375,"recommendedApproach":390,"relations":392,"seo":399,"stem":402,"summary":403,"visuals":404,"__hash__":407},"useCases_en\u002Fuse-cases\u002Fprototype-naar-onderhoudbaar-softwareproduct.md","We want to go from prototype to a maintainable software product",{"type":23,"value":332,"toc":333},[],{"title":26,"searchDepth":27,"depth":27,"links":334},[],{"intro":336,"items":337},"Starting over isn't a given. What you want is a technical foundation on which a normal development team can keep building responsibly.\n",[338,341,344],{"title":339,"text":340},"Understandable architecture","It's clear where responsibilities and business logic belong.\n",{"title":342,"text":343},"A safe development cycle","Tests, deployment and error handling support frequent change.\n",{"title":345,"text":346},"Less knowledge in people's heads","Important technical choices and processes are sufficiently documented.\n",{"intro":348},"A prototype mainly has to answer one question quickly: does the idea work? A software product also has to stay understandable, survive changes and be maintainable by more than one person.\n",{},"\u002Fuse-cases\u002Fprototype-naar-onderhoudbaar-softwareproduct",{"intro":352,"causes":353},"Prototype code is optimised for speed of learning. Product software also has to be optimised for change.\n",[354,357,360],{"title":355,"text":356},"Architecture lagged behind product development","The prototype grew organically while requirements kept changing.\n",{"title":358,"text":359},"Temporary assumptions became structural","Choices that were logical for an experiment now determine how the whole product works.\n",{"title":361,"text":362},"Maintainability was not yet a success criterion","Tests, documentation and clear boundaries delivered little direct value during the first validation.\n",{"intro":364,"points":365},"9to5 software combines AI with regular senior software engineering. That is exactly what matters when a smart prototype has to become a durable product.\n",[366,369,372],{"title":367,"text":368},"Keep what works","A rewrite is one possible choice, not the default answer.\n",{"title":370,"text":371},"Maintainability is practical","We focus on changing, testing and releasing more safely.\n",{"title":373,"text":374},"Built for the next team","Software must stay understandable without its original builder too.\n",{"intro":376,"signals":377},"A lot of prototype code isn't bad at all. You just see more and more clearly where speed was chosen over maintainability.\n",[378,381,384,387],{"title":379,"text":380},"Temporary solutions have become permanent","Scripts, hardcoded values and shortcuts are now used by real flows.\n",{"title":382,"text":383},"New features take more and more effort","The existing structure no longer fits well with what the product has become.\n",{"title":385,"text":386},"Only one person understands critical parts","Knowledge transfer becomes hard and changes feel risky.\n",{"title":388,"text":389},"Releases are largely manual work","Deployment and configuration need steps that are easily forgotten or done wrong.\n",{"intro":391},"With a Vibe Code Rescue Audit we determine what forms a good foundation and what really holds development back. Build & Integrate can then carry out the larger professionalisation without automatically rebuilding the whole product.\n",{"buyerTriggerKeys":393,"primaryOfferKey":82,"offerKeys":394,"caseKeys":395,"relatedUseCaseKeys":396},[106],[82,113],[],[397,398],"ai-prototype-naar-productie","vibe-coded-app-professionaliseren",{"title":400,"description":401},"From prototype to maintainable software product | 9to5 software","Developing a prototype into maintainable software? 9to5 helps get architecture, code, tests, deployment and documentation ready for long-term use.\n","use-cases\u002Fprototype-naar-onderhoudbaar-softwareproduct","The core works, but the software has to be built so that a team can still change it safely in six or twelve months.\n",{"hero":405,"problem":164,"proof":406},"sq-foundation-build","ls-prototype-to-production","DfBDuBl23pxVzfnTmE43TF-OjYwrcBmYDpM95_zySzw",1792049913719]