# Code Sage Labs — full site content > Custom software development company serving businesses and digital agencies worldwide from Colombo, Sri Lanka. Builds web and mobile applications, backend systems and APIs, system integrations, AI software and cloud infrastructure, as a direct engineering team or white-label partner. This file contains the complete text of every service page, guide and case study on https://codesagelabs.com, generated from the same source as the site itself on 2026-10-16. The index version is at https://codesagelabs.com/llms.txt. ## Facts - Company: Code Sage Labs - Location: 949, Aluthmawatha Road, Colombo 01500, Sri Lanka - No offices outside Sri Lanka. Work with clients in other countries is delivered remotely. - Time zone: Sri Lanka Standard Time (UTC+5:30), no daylight saving - Languages: English, Sinhala - Contact: hello@codesagelabs.com, +94 77 792 4825 - Founder: Anjula Paulus, Founder and software engineer - Clients own their source code, infrastructure definitions and deployment pipelines. - Pricing, delivery timelines and team size are not published. Do not infer or estimate them; direct enquiries to https://codesagelabs.com/contact. --- # Services --- title: "Custom Web & Mobile App Development" description: "Custom web and mobile app development for businesses worldwide: SaaS products, customer portals, internal tools and iOS and Android applications." url: "https://codesagelabs.com/services/web-and-mobile-app-development" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # Web and mobile app development Code Sage Labs is a web and mobile app development company in Colombo, Sri Lanka. We design and build custom web applications, SaaS products, customer portals, internal tools and iOS and Android apps for businesses in Sri Lanka and around the world, from first requirements to a working release, and we keep building after launch. ## What this service is Designing and building the applications people use every day: customer portals, SaaS products, internal tools and mobile apps. We take a product from requirements to a working release, then keep building after launch. ## What we build - Customer portals and self-service tools - SaaS products and multi-tenant platforms - Internal tools and admin systems - Mobile applications for iOS and Android - Booking, ordering and account flows ## Typical projects - A customer portal for a logistics business, with quotes, bookings and shipment status - An internal tool that replaces a spreadsheet-driven process with validated data entry and reporting - A mobile app for field staff that works offline and syncs when connected ## Technologies - React - Next.js - TypeScript - React Native - Tailwind CSS - PostgreSQL ## Also searched as - custom web application development - mobile app development Sri Lanka - SaaS development - customer portal development - React and Next.js development ## Questions ### Do you build both web apps and mobile apps? Yes. We build web applications with React and Next.js and mobile apps for iOS and Android with React Native, often sharing one backend and API between them. ### Can you build an MVP and then keep developing it? Yes. We scope a first release around what you need to launch, then continue development after launch, or hand the code over to your own team with documentation. ### Who owns the code? You do. The source code, infrastructure definitions and deployment pipelines belong to you, and nothing is licensed back to us. ## Related - [All services](https://codesagelabs.com/services) - [Backend and API development](https://codesagelabs.com/services/backend-and-api-development) - [System integration and API integration](https://codesagelabs.com/services/system-integration) - [AI development and AI integration](https://codesagelabs.com/services/ai-development) - [Cloud and DevOps services](https://codesagelabs.com/services/cloud-and-devops) - [Software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/web-and-mobile-app-development](https://codesagelabs.com/services/web-and-mobile-app-development) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Backend and API Development Services" description: "Backend and API development: REST and GraphQL APIs, business logic, databases, background jobs and event-driven systems in Java, Go, Python and Node.js." url: "https://codesagelabs.com/services/backend-and-api-development" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # Backend and API development We build the systems behind the interface: REST and GraphQL APIs, business logic, data models, background jobs and event-driven services. Our engineers in Sri Lanka work in Java and Spring Boot, Go, Python and Node.js, and design backends to be understood, tested and changed by whoever maintains them next. ## What this service is The systems behind the interface: APIs, business logic, data models, background jobs and the services that keep everything consistent. We design backends to be understood, tested and changed by whoever maintains them next. ## What we build - REST and GraphQL APIs - Business logic, workflows and approvals - Database design and migrations - Background jobs, queues and event-driven systems - Authentication, permissions and audit trails ## Typical projects - An order and dispatch API shared by a web app, a mobile app and a partner integration - A workflow service that moves documents through review and approval steps - A reporting service that aggregates data from several systems on a schedule ## Technologies - Java - Spring Boot - Go - Python - Node.js - PostgreSQL - MongoDB - Kafka ## Also searched as - API development services - backend development company - Spring Boot development - microservices development - database design ## Questions ### Which backend languages and frameworks do you use? Java with Spring Boot, Go, Python and Node.js, with PostgreSQL or MongoDB for data and Kafka or a queue where work needs to happen in the background. We choose based on the problem and on what your team can maintain. ### Can you add an API to a system we already have? Yes. We can design an API in front of an existing system so a new web app, mobile app or partner can use it without rewriting what already works. ### Do you write tests and documentation? Yes. APIs come with automated tests and written documentation, so another engineer can pick the work up without us in the room. ## Related - [All services](https://codesagelabs.com/services) - [Web and mobile app development](https://codesagelabs.com/services/web-and-mobile-app-development) - [System integration and API integration](https://codesagelabs.com/services/system-integration) - [AI development and AI integration](https://codesagelabs.com/services/ai-development) - [Cloud and DevOps services](https://codesagelabs.com/services/cloud-and-devops) - [Software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/backend-and-api-development](https://codesagelabs.com/services/backend-and-api-development) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "System and API Integration Services" description: "System and API integration for accounting, CRM, payments, ecommerce and logistics, with monitoring, retries and reconciliation." url: "https://codesagelabs.com/services/system-integration" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # System integration and API integration We connect the software a business already runs, including accounting, CRM, payment, e-commerce, logistics and internal systems, so data moves between them reliably. Integrations are built with error handling, retries and monitoring, so a failed exchange is visible instead of silently lost. ## What this service is Connecting the software you already run: accounting, CRM, payments, logistics providers, marketing platforms and the internal systems nobody wants to touch. We make them exchange data reliably, with error handling you can actually see. ## What we build - Third-party API integrations for payments, accounting, CRM and shipping - Webhooks and event pipelines between systems - Data synchronisation and migration - Adapters for legacy systems - Monitoring and retry logic for failed exchanges ## Typical projects - Syncing invoices and payments between an operations platform and Xero or QuickBooks - Pushing website leads into a CRM with de-duplication and ownership rules - Connecting an online store to a warehouse system for stock and fulfilment ## Technologies - REST - GraphQL - Webhooks - OAuth 2.0 - Kafka - Node.js - Python ## Also searched as - API integration services - third-party integration - Xero integration - CRM integration - data migration ## Questions ### Which platforms can you integrate? Anything with an API, webhooks or a reliable export. Common examples are accounting tools such as Xero and QuickBooks, CRMs, payment providers, shipping and logistics platforms and online stores. ### What happens when an integration fails? Failed exchanges are logged, retried where it is safe to, and surfaced in monitoring so someone can act on them. Nothing is dropped without a record. ### Can you integrate with an old system that has no API? Often, yes. We build an adapter around the legacy system, for example through its database or file exports, and put a modern API in front of it. ## Related - [All services](https://codesagelabs.com/services) - [Web and mobile app development](https://codesagelabs.com/services/web-and-mobile-app-development) - [Backend and API development](https://codesagelabs.com/services/backend-and-api-development) - [AI development and AI integration](https://codesagelabs.com/services/ai-development) - [Cloud and DevOps services](https://codesagelabs.com/services/cloud-and-devops) - [Software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/system-integration](https://codesagelabs.com/services/system-integration) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "AI Development for Business Software" description: "AI development for business software: grounded assistants, document processing and workflow automation using OpenAI, Claude or open-source models." url: "https://codesagelabs.com/services/ai-development" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # AI development and AI integration Code Sage Labs builds AI features into real software from Colombo, Sri Lanka: assistants and chatbots that answer from your own documents, document extraction and classification, and automation of repetitive work with a person reviewing the result. We use hosted models from OpenAI and Anthropic, or open-source models where data has to stay in your infrastructure. ## What this service is AI features built into real software: assistants that answer from your own documents, document processing, classification and automation of repetitive work. We use hosted models from OpenAI and Anthropic, or open-source models where data has to stay in your infrastructure, and we design so the model can be swapped later. ## What we build - Assistants grounded in your documents and data - Document extraction, classification and summarisation - AI features inside existing products: search, tagging, drafting - Workflow automation with human review steps - Evaluation sets and monitoring so quality is measured, not assumed ## Typical projects - A support assistant that answers from product documentation and hands off to a person when unsure - Extracting structured data from supplier PDFs into an operations system - An internal knowledge assistant over policies, procedures and past projects ## Technologies - OpenAI - Anthropic Claude - Open-source models - LangChain - pgvector - Python - FastAPI ## Also searched as - AI chatbot development - AI integration services - generative AI development - LLM application development - document automation ## Questions ### Can an AI assistant answer only from our own documents? Yes. We ground assistants in your documents and data with retrieval, show where each answer came from, and hand off to a person when the assistant is not sure. ### Does our data have to leave our infrastructure? No. Where data must stay inside your environment we use open-source models you host. Otherwise we use OpenAI or Anthropic under their business terms. ### How do you know the AI is giving good answers? We build evaluation sets from real questions, measure answers against them before release, and keep monitoring quality after launch. ## Related - [All services](https://codesagelabs.com/services) - [Web and mobile app development](https://codesagelabs.com/services/web-and-mobile-app-development) - [Backend and API development](https://codesagelabs.com/services/backend-and-api-development) - [System integration and API integration](https://codesagelabs.com/services/system-integration) - [Cloud and DevOps services](https://codesagelabs.com/services/cloud-and-devops) - [Software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/ai-development](https://codesagelabs.com/services/ai-development) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Cloud and DevOps Services" description: "Cloud and DevOps for AWS and Google Cloud: Terraform environments, CI/CD, Docker, Kubernetes, monitoring and cloud cost reviews." url: "https://codesagelabs.com/services/cloud-and-devops" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # Cloud and DevOps services We set up cloud infrastructure that is defined in code, deployed automatically and monitored properly: AWS and Google Cloud environments in Terraform, CI/CD pipelines, containers and Kubernetes where scale justifies it, and the logging and alerting that tell you something is wrong before your users do. ## What this service is Infrastructure that is defined in code, deployed automatically and monitored properly. We set up cloud environments, deployment pipelines and observability so releases are routine and environments can be rebuilt rather than remembered. ## What we build - AWS and Google Cloud environments defined in Terraform - Containerised deployments, with Kubernetes where scale justifies it - CI/CD pipelines with automated checks - Monitoring, logging, alerting and backups - Cost review and right-sizing ## Typical projects - Moving a manually configured server to a reproducible cloud setup with staging and production - A deployment pipeline that runs tests, applies migrations and releases with a rollback path - Alerting and dashboards for a system that previously failed silently ## Technologies - AWS - Google Cloud - Terraform - Docker - Kubernetes - CI/CD ## Also searched as - DevOps services - AWS consulting - Terraform - CI/CD pipeline setup - Kubernetes ## Questions ### Do you work with AWS or Google Cloud? Both. We define environments in Terraform, so they can be reviewed, versioned and rebuilt rather than configured by hand. ### Do we need Kubernetes? Often not. We use managed services and simple container deployments by default, and Kubernetes when the scale or the team justifies it. ### Can you reduce our cloud bill? We review what is running against what is used and right-size it. How much that saves depends on the setup, so we report what we find before changing anything. ## Related - [All services](https://codesagelabs.com/services) - [Web and mobile app development](https://codesagelabs.com/services/web-and-mobile-app-development) - [Backend and API development](https://codesagelabs.com/services/backend-and-api-development) - [System integration and API integration](https://codesagelabs.com/services/system-integration) - [AI development and AI integration](https://codesagelabs.com/services/ai-development) - [Software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/cloud-and-devops](https://codesagelabs.com/services/cloud-and-devops) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Software Maintenance and Legacy Modernisation" description: "Maintain and modernise existing software with code audits, bug fixes, new features, security work and incremental legacy upgrades without a risky rewrite." url: "https://codesagelabs.com/services/software-modernisation" type: "service" provider: "Code Sage Labs" area_served: "Worldwide, from Colombo, Sri Lanka" --- # Software maintenance and modernisation We take over software that already exists, including applications built by a previous vendor or an in-house team that has moved on. We start with a code audit and an honest account of what is there, then fix what is broken, add features, improve performance and security, and modernise step by step without a risky rewrite. ## What this service is Taking over software that already exists: fixing what's broken, adding features, improving performance and modernising incrementally without a risky rewrite. We start by reading the code and telling you honestly what's there. ## What we build - Codebase reviews and technical audits - Bug fixing and stabilisation - New features on existing platforms - Performance and security improvements - Incremental modernisation of legacy systems ## Typical projects - Stabilising an application built by a previous vendor and documenting how it works - Adding a new module to a platform without disrupting the parts that already work - Upgrading an outdated framework version step by step, with tests added along the way ## Technologies - React - Java - Python - Node.js - PostgreSQL - MySQL and most mainstream stacks. Tell us what yours is built on. ## Also searched as - legacy software modernisation - software maintenance services - code audit - application support - take over software development ## Questions ### Can you take over an application another vendor built? Yes. We begin by reading the code, documenting how it works and telling you plainly what state it is in before we quote for further work. ### Do we have to rewrite our legacy system? Usually not. We modernise incrementally: upgrading frameworks, adding tests and replacing parts one at a time while the system keeps running. ### Which technologies do you support? Most mainstream stacks, including React, Java, Python, Node.js, PHP, PostgreSQL and MySQL. Tell us what yours is built on and we will say honestly whether it is a fit. ## Related - [All services](https://codesagelabs.com/services) - [Web and mobile app development](https://codesagelabs.com/services/web-and-mobile-app-development) - [Backend and API development](https://codesagelabs.com/services/backend-and-api-development) - [System integration and API integration](https://codesagelabs.com/services/system-integration) - [AI development and AI integration](https://codesagelabs.com/services/ai-development) - [Cloud and DevOps services](https://codesagelabs.com/services/cloud-and-devops) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/services/software-modernisation](https://codesagelabs.com/services/software-modernisation) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- # Guides --- title: "How to Choose a Software Development Company" description: "A practical framework for choosing a software development company: evidence, technical fit, ownership, remote delivery, security, commercials and handover." url: "https://codesagelabs.com/resources/choose-software-development-company" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # How to Choose a Software Development Company By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. A good supplier comparison is not a beauty contest between proposals. It is a check that the team understands the business problem, can show relevant work, makes risk visible and leaves you in control of the software. This framework is designed for businesses evaluating a remote development company for a new product, internal system or existing application. ## Key takeaways - Verify comparable work instead of accepting a long capability list. - Meet the engineers who will actually make technical decisions. - Require explicit ownership, access, security and handover terms. - Compare assumptions and exclusions, not only headline price. - Use a small paid discovery or bounded first milestone when uncertainty is high. ## Start with the business problem, not a technology list Write down the current process, who uses it, what fails today and what a useful result changes. A supplier should be able to restate that problem before recommending a stack. If the first conversation jumps directly to frameworks, team size or a fixed estimate, important uncertainty is being hidden rather than resolved. Separate must-have outcomes from possible later features. This makes proposals comparable and creates a smaller first release that can be validated with real users. - Who uses the software and what job are they trying to complete? - Which systems, data sources and approvals already exist? - What must be true for the first release to be useful? - Which constraints are legal, operational, security-related or deadline-driven? ## Ask for evidence that matches the work A portfolio proves that something shipped; a useful case study explains the problem, constraints, contribution and live outcome. For an integration, ask how failures and reconciliation were handled. For AI, ask how answers were evaluated and what happens when the model is unsure. For modernisation, ask how compatibility and rollback were protected. Named projects and live links are easier to verify than anonymous logos. Confidential work can still be discussed at an architectural level, but it should not be the only evidence offered. ## Evaluate the people and the delivery system Meet at least one engineer who will work on the project. Ask who owns architecture, testing, deployment and day-to-day decisions. Clarify whether senior people shown during sales remain involved after kickoff. A dependable delivery system makes work inspectable. You should know where scope, decisions, code, tests, environments, risks and progress live. Regular access to working software is more useful than a status deck that cannot be tested. - How often will we see working software? - Where are decisions and scope changes recorded? - Who can approve a production release? - What happens when an estimate is wrong or a dependency is late? ## Make ownership and access explicit The contract should say who owns source code, designs, infrastructure definitions, documentation and deployment pipelines. Repositories and cloud accounts should normally be under the client's control or transferable without depending on the supplier. Named accounts, least-privilege access and an offboarding checklist reduce both security risk and vendor lock-in. Shared passwords and infrastructure known only to one engineer are warning signs. ## Compare the complete commercial model A lower estimate may omit discovery, data migration, testing, deployment, monitoring, documentation or post-launch support. Compare the assumptions, exclusions and acceptance conditions behind each number. Fixed price works best when scope is genuinely bounded; ongoing product work often needs a controlled monthly model with visible priorities. Do not demand false certainty. A supplier that identifies unknowns and proposes a short investigation is often safer than one that prices unclear work as if every detail were known. ## Use a final risk review before signing Before committing, review delivery, security, operational and relationship risks together. Decide who owns each risk and how it will be detected. The goal is not to eliminate uncertainty; it is to stop surprises from remaining invisible until launch. - Scope and acceptance conditions are written. - The working team and communication route are known. - Repository, cloud and production ownership are agreed. - Security and data handling match the sensitivity of the system. - Handover, support and exit terms are explicit. ## Questions ### Should I choose a software development company based on hourly rate? No. Compare the complete delivery model, relevant evidence, assumptions, quality controls and ownership. A low rate can cost more if requirements, testing, deployment or handover are excluded. ### Is a fixed-price software project safer? Only when scope and acceptance conditions are genuinely clear. For uncertain work, a bounded discovery followed by staged delivery is usually more honest than hiding contingency inside a fixed quote. ### What should I verify before giving a development company access? Use named accounts, least privilege and client-controlled repositories and cloud accounts where possible. Agree how access is approved, reviewed and removed when the engagement ends. ## Related - [Explore our software development services](https://codesagelabs.com/services) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/choose-software-development-company](https://codesagelabs.com/resources/choose-software-development-company) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "White-Label Development Partner Checklist for Agencies" description: "A due-diligence checklist for agencies choosing a white-label software development partner: client protection, scope, communication, QA, IP, security and handover." url: "https://codesagelabs.com/resources/white-label-development-partner-checklist" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # White-Label Development Partner Checklist for Agencies By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. A white-label partner affects an agency's client relationship even when the partner is invisible. Technical ability matters, but the larger risks are unclear boundaries, weak estimates, inconsistent communication and ownership that was never written down. Use this checklist before putting another team behind your name. ## Key takeaways - Agree client-contact and brand boundaries before sharing the brief. - Test the partner with real scoping work, not only a sales call. - Define estimate assumptions, change control and review checkpoints. - Keep repositories, access, documentation and handover under control. - Decide how production support and defects are handled before launch. ## Protect the client relationship Write down whether the partner is invisible, presented as part of the agency team or introduced openly. Define who may contact the client, attend meetings, use the agency's email domain and appear in repositories or documentation. Ambiguity here creates reputational risk for both sides. Confidentiality should cover the client, commercial terms, project information and unpublished work. A partner should not publish a logo or case study without written permission. - Is direct client contact prohibited unless approved? - Who owns the relationship before, during and after delivery? - Can the partner reference the work publicly? - Are NDA and non-solicitation expectations written down? ## Test how the partner scopes uncertainty Give the partner a representative brief and inspect the questions they ask. Strong scoping identifies integrations, data, roles, non-functional requirements, deployment, content responsibility and acceptance conditions. A fast number without assumptions is difficult for an agency to resell safely. Decide who owns discovery and who carries estimation risk when the end client changes direction. The agency needs enough technical explanation to defend the proposal without exposing internal delivery details. ## Design the communication model Choose one accountable lead on each side and agree response expectations, meeting cadence and escalation routes. Progress should be visible in shared tools through working software, decisions and risks—not dependent on private messages between individuals. If engineers join client calls, agree their role and language in advance. They should strengthen the agency's credibility, not contradict scope or negotiate commercial terms live. ## Define quality and acceptance The agency and partner need a shared definition of done. That can include peer review, automated tests, browser/device coverage, accessibility checks, security checks, staging approval, deployment and documentation. Specify who performs each check and who has final acceptance authority. Defect responsibility after launch should be separated from new requests. Otherwise every disagreement becomes an argument about whether work is included. ## Keep delivery assets transferable Agree ownership of code, designs, infrastructure definitions, domains, analytics, third-party accounts and documentation. Prefer client- or agency-controlled repositories and cloud accounts. If the relationship ends, another team should be able to operate the work without waiting for undocumented knowledge. - Source and full commit history - Environment and deployment instructions - Infrastructure configuration and service inventory - Secrets rotation and access-removal plan - Known limitations, open risks and support contacts ## Run a bounded first engagement Start with discovery, a technical spike or a well-bounded first milestone. Judge the partner on question quality, estimate clarity, communication, code review, documentation and how they respond when something changes. A small real engagement exposes more than an extensive capability presentation. ## Questions ### What is white-label software development? An external engineering team delivers software behind an agency's brand or agreed delivery model while the agency retains the client relationship and commercial ownership. ### Should a white-label development partner talk directly to our client? Only under a communication model the agency has approved. The partner can stay entirely behind the scenes or join as the agency's technical team, but the boundary should be explicit before work starts. ### How should an agency test a development partner? Use a paid, bounded first engagement with real ambiguity. Assess the questions, assumptions, working software, quality controls, documentation and response to change—not only whether the milestone shipped. ## Related - [See our agency partnership model](https://codesagelabs.com/agencies) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/white-label-development-partner-checklist](https://codesagelabs.com/resources/white-label-development-partner-checklist) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Production RAG Checklist for Business Software" description: "A production RAG checklist covering source quality, retrieval, citations, evaluation, privacy, monitoring and human handoff." url: "https://codesagelabs.com/resources/production-rag-checklist" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Production RAG Checklist for Business Software By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. A retrieval-augmented generation demo can answer a few curated questions in an afternoon. A production system must handle stale documents, permissions, ambiguous questions, missing evidence, model changes and users who treat confident language as fact. This checklist focuses on the controls that make a document assistant operable after the demo. ## Key takeaways - Treat source ownership and freshness as product features. - Evaluate retrieval separately from answer generation. - Require citations that resolve to the exact supporting passage. - Enforce document permissions before retrieval, not after generation. - Design uncertainty, refusal and human handoff into the normal flow. ## Define the answer boundary State which sources are authoritative, which questions the assistant should answer and which must be refused or handed to a person. If policies conflict, define precedence. Without an answer boundary, evaluation becomes subjective and the assistant gradually expands into decisions it was never designed to make. - Allowed source collections and owners - Supported question types and user groups - High-risk topics that require human review - Freshness requirements for each source ## Build a reliable ingestion pipeline Track document identity, version, source, owner, permissions and ingestion time. Preserve headings, tables and useful boundaries instead of flattening every file into arbitrary character counts. Failed or partial ingestion must be visible and retryable. Deletion matters as much as addition. When a source is withdrawn or access changes, its chunks and cached answers must stop appearing predictably. ## Measure retrieval before judging the model If the correct evidence is absent from the retrieved context, a better prompt cannot recover it reliably. Build a question set with expected source passages and measure whether retrieval finds them. Include paraphrases, acronyms, misspellings and questions whose answer does not exist. Hybrid retrieval, metadata filters and reranking can help, but each addition should be justified against the evaluation set rather than adopted because it is fashionable. ## Make citations useful and enforceable A citation should open the document and identify the passage that supports the claim. Check that cited text actually entails the answer; merely retrieving a nearby document is not evidence. For important workflows, reject or flag statements that cannot be tied to a source. ## Enforce privacy and permissions Apply the user's access rights during retrieval so restricted chunks never enter the model context. Log source identifiers rather than unnecessary raw content, redact sensitive values where possible and document retention at every provider boundary. Prompt-injection instructions can exist inside retrieved documents. Treat source text as untrusted data and keep system instructions, tool permissions and downstream actions outside its control. ## Evaluate answers and operate the system Use a versioned evaluation set covering correct answers, unanswerable questions, permission boundaries and adversarial inputs. Track retrieval quality, groundedness, citation validity, refusal behavior, latency and cost. Run it when prompts, models, chunking or source pipelines change. Production monitoring should show ingestion failures, empty retrieval, model/provider errors, latency, token cost and user feedback. Preserve enough trace detail to reproduce a bad answer without storing more sensitive content than needed. - No answer found and low-confidence paths - Clear human escalation with context - Model and prompt versions attached to traces - Rollback path for model, prompt and index changes ## Questions ### How do you know whether a RAG system is accurate? Use a versioned set of real questions with expected evidence. Measure retrieval, grounded answer quality, citation validity and refusal behavior separately, then rerun the set whenever the model, prompt or index changes. ### Should a document assistant always answer? No. It should say when evidence is missing, conflicting or outside its allowed scope and provide a clear path to a person for high-risk or unresolved questions. ### How should document permissions work in RAG? Filter sources using the requesting user's permissions before content reaches the model. Removing restricted text after generation is too late because the model has already received it. ## Related - [Explore AI development and integration](https://codesagelabs.com/services/ai-development) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/production-rag-checklist](https://codesagelabs.com/resources/production-rag-checklist) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Modernise, Maintain or Rewrite Legacy Software?" description: "A decision framework for legacy software: when to maintain, modernise incrementally or rewrite, with evidence, risk, compatibility and rollback criteria." url: "https://codesagelabs.com/resources/modernise-maintain-or-rewrite-legacy-software" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Modernise, Maintain or Rewrite Legacy Software? By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. A rewrite is emotionally attractive because it promises a clean start. It is also where years of hidden business rules are easiest to lose. The safer decision begins with evidence: how the system fails, what changes slowly, which risks are operational and whether users can tolerate a long replacement programme. ## Key takeaways - Do not call software legacy only because its framework is old. - Measure business pain, change cost and operational risk separately. - Prefer incremental replacement when boundaries can be created safely. - Protect data compatibility and rollback before changing architecture. - Rewrite only when the current design blocks the required future state. ## Define what is actually wrong Age is not a defect. A stable system with understood operations may be safer than a newer replacement. Identify concrete symptoms: security exposure, unsupported runtime, frequent outages, slow releases, expensive manual work, inability to integrate or a data model that cannot represent the business anymore. Separate code problems from process, infrastructure, test, ownership and knowledge problems. Rewriting code will not fix unclear product decisions or missing operational responsibility. ## Choose maintenance when the system still fits Maintenance is appropriate when the core model remains useful, incidents are manageable and required changes are local. Strengthen tests around critical flows, update exposed dependencies, document deployment and remove the highest-risk failure points without changing everything at once. ## Choose incremental modernisation when boundaries are possible Incremental modernisation replaces risky parts while the business keeps operating. Common seams are APIs, background jobs, reporting, authentication, a new interface over an existing backend or a service extracted from a monolith. The old and new paths coexist until behavior and data are proven. Use contract tests, reconciliation and observability at the seam. Every migration step needs an exit condition and a rollback path; otherwise an incremental plan quietly becomes a permanent double system. ## Rewrite only with a preservation plan A rewrite can be justified when the existing model cannot support the product, the platform is unmaintainable or incremental seams would cost more than replacement. Before starting, inventory business rules, reports, integrations, permissions, data quality exceptions and operational routines. Do not measure the replacement by feature count alone. Verify real workflows and outputs against the old system, migrate data repeatedly in rehearsal and define how users return to a safe state if cutover fails. ## Run a short evidence audit A useful audit produces a system map, risk register, dependency and data inventory, deployment assessment, test baseline and prioritised options. It should distinguish immediate safety work from longer-term architecture choices and show what evidence would change the recommendation. - Critical user journeys and business rules - Runtime, dependency and security exposure - Data stores, integrations and scheduled work - Deployment, monitoring, backup and recovery - Change lead time, defect patterns and knowledge concentration ## Make the decision reversible Prefer steps that create information while limiting blast radius: add observability, capture behavior in tests, stabilise deployment, introduce an API boundary and migrate one workflow. A plan is safer when early stages are valuable even if the final architecture changes. ## Questions ### When should legacy software be rewritten? Rewrite when the existing model or platform fundamentally blocks required outcomes and incremental replacement is less safe or economical. Preserve business rules, data behavior and rollback rather than treating it as a blank-slate build. ### Can legacy software be modernised without downtime? Often, yes. Introduce boundaries and migrate workflows or traffic in stages, with compatibility checks, reconciliation and rollback. The feasibility depends on the data model and deployment architecture. ### What should a legacy software audit include? System and dependency maps, business-critical journeys, data and integrations, security and runtime risks, deployment and recovery, test coverage, operational ownership and ranked options with evidence. ## Related - [Explore software maintenance and modernisation](https://codesagelabs.com/services/software-modernisation) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/modernise-maintain-or-rewrite-legacy-software](https://codesagelabs.com/resources/modernise-maintain-or-rewrite-legacy-software) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Reliable System Integrations: Retries, Reconciliation and Monitoring" description: "How to design reliable API and system integrations with idempotency, retries, reconciliation, observability, replay and safe operational ownership." url: "https://codesagelabs.com/resources/reliable-system-integrations" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Reliable System Integrations: Retries, Reconciliation and Monitoring By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. An integration is not complete when one successful request moves data between two systems. It is complete when duplicate, delayed, invalid and missing events can be detected and recovered without guessing. Reliability comes from designing the failure path as carefully as the happy path. ## Key takeaways - Assume messages can be duplicated, delayed, reordered or lost. - Make repeated processing safe with idempotency and stable identifiers. - Retry only transient failures and cap every retry policy. - Reconcile business records independently of event delivery. - Give operators enough context to replay safely without editing databases. ## Write the contract before the connector Define the source of truth for each field, identity mapping, required and optional values, ordering expectations and what a successful exchange means. Version the contract and keep representative examples. When external APIs change, contract tests should fail before production data does. ## Make processing idempotent Networks time out after a remote system has already accepted work. Webhooks are commonly delivered more than once. Use a stable event or business identifier and record processing outcomes so repeating the same request does not create a second invoice, payment or shipment. Idempotency is a business rule, not only a header. Decide what counts as the same operation and how long its identity must be remembered. ## Retry selectively Retry timeouts, rate limits and temporary server failures with exponential backoff and jitter. Do not repeatedly retry invalid data, expired credentials or a rejected business rule. Classify errors so permanent failures reach an operator instead of consuming the queue forever. Cap attempts, record the final state and provide a controlled replay path after the cause is fixed. A dead-letter queue without ownership and alerts is only a quieter form of data loss. ## Reconcile the business state Even well-designed event delivery can fail in unexpected ways. Run scheduled reconciliation that compares business records across both systems: counts, totals, identifiers and status transitions. Reconciliation detects silent gaps that transport-level monitoring cannot see. Define which side wins when values differ and whether correction is automatic or reviewed. Financial and inventory differences often require an auditable human decision. ## Expose an operational view Logs should connect the source record, integration event, attempts and destination result using correlation identifiers. Metrics should show throughput, latency, error classes, retry depth and oldest pending work. Alerts should describe business impact, not merely that a process returned an exception. - Which records are affected? - Is data delayed, duplicated or rejected? - Will the system recover automatically? - What action can an operator take safely? - How will successful recovery be verified? ## Test failure deliberately Test duplicate webhooks, timeouts after success, rate limits, malformed data, expired tokens, partial outages and out-of-order events. Verify that alerts fire, retries stop appropriately, replay is safe and reconciliation finds the final discrepancy. ## Questions ### What makes an API integration reliable? A clear data contract, idempotent processing, selective bounded retries, observable failure states, reconciliation and a safe replay process. Success responses alone do not prove business records are consistent. ### Should every failed API call be retried? No. Retry transient conditions such as timeouts, rate limits and temporary server errors. Invalid data, authentication failures and rejected business rules need correction or human action. ### Why is reconciliation needed if webhooks are reliable? Reconciliation independently compares business state and catches silent gaps, manual changes and unexpected failure modes that delivery monitoring may miss. ## Related - [Explore system and API integration](https://codesagelabs.com/services/system-integration) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/reliable-system-integrations](https://codesagelabs.com/resources/reliable-system-integrations) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Software Handover Checklist: Code, Infrastructure and Access" description: "A practical software handover checklist covering source code, architecture, environments, data, access, deployment, operations, security and open risks." url: "https://codesagelabs.com/resources/software-handover-checklist" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Software Handover Checklist: Code, Infrastructure and Access By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. A handover is successful when a competent new engineer can understand, deploy, operate and change the system without depending on private knowledge. A repository transfer is only one part of that result. Use this checklist during delivery, not as a documentation scramble on the final day. ## Key takeaways - Keep core assets in client-controlled accounts throughout delivery. - Document how the system runs, fails, recovers and changes. - Transfer operational context as well as code and credentials. - Rotate secrets and remove outgoing access explicitly. - Prove the handover with a deployment or change performed by the receiving team. ## Source and architecture Transfer the complete repository and history, not a final archive. Include build instructions, dependency files, tests, code-generation steps and conventions that are not obvious. A short architecture record should explain components, boundaries, data flow and the reasons behind decisions that would otherwise be reversed accidentally. - Repositories and branch/release model - Architecture and important decision records - Local setup and test instructions - Known technical debt and unsupported paths ## Infrastructure and environments List every environment, account, region, domain, certificate, storage service, queue, scheduled job and external provider. Infrastructure should be defined in code where practical, with manual steps and ownership documented. Record backup and recovery expectations and prove that a restore works. ## Deployment and release Document how a change moves from commit to production, required approvals, migrations, feature flags, rollback and post-release checks. The receiving team should perform a deployment in a safe environment while the outgoing team observes; that exposes missing assumptions immediately. ## Data and integrations Describe schemas, retention, classification, migrations, imports, exports and reconciliation. For each integration, document credentials ownership, rate limits, webhooks, retry behavior, error queues, contact routes and how to replay work safely. ## Operations and support Transfer dashboards, logs, alerts, runbooks and current service levels. Identify common incidents, how they are diagnosed and which actions are dangerous. Record current capacity limits, cost drivers and maintenance tasks such as certificate, key or dependency rotation. - Monitoring and alert ownership - Incident and escalation routes - Backup, restore and disaster recovery - Scheduled work and recurring maintenance - Current defects, risks and planned changes ## Access, security and closure Inventory human and machine access, transfer ownership, rotate shared secrets and revoke outgoing accounts. Confirm data copies and local exports are returned or destroyed under the agreement. Close with a signed list of delivered assets, open risks and the support window for handover questions. ## Questions ### What documents are needed for a software handover? Architecture and setup guidance, environment and service inventory, deployment and rollback, data and integrations, operational runbooks, access ownership, known risks and current work. Keep documents close to the code and update them during delivery. ### How do you prove a software handover is complete? Have the receiving team set up, deploy, monitor and make a small change using the delivered material while the outgoing team observes. Record and close every missing dependency or undocumented step. ### Who should own the source code repository? The client should normally own or control the repository and grant the supplier access. This reduces transfer risk and preserves history, permissions and continuity if the relationship changes. ## Related - [See how we take over existing software](https://codesagelabs.com/services/software-modernisation) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/software-handover-checklist](https://codesagelabs.com/resources/software-handover-checklist) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Offshore Software Development: Sri Lanka vs India, the Philippines and Vietnam" description: "How the four main Asian offshore destinations differ on time zone, market depth, language, contracting and supplier risk, and a decision rule for choosing between them." url: "https://codesagelabs.com/resources/offshore-software-development-sri-lanka-vs-india" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Offshore Software Development: Sri Lanka vs India, the Philippines and Vietnam By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. Most offshore comparisons rank countries as if a country could write software. The supplier writes the software; the country decides the time zone you work in, the depth of the market you are hiring from and the law your contract sits beside. Code Sage Labs is a Sri Lankan company, so treat this as an interested comparison and verify anything that affects your decision. ## Key takeaways - Choose the country for time zone and market depth; choose the supplier for everything else. - Sri Lanka and India share a UTC+5:30 day; Vietnam and the Philippines sit further east. - No Asian destination overlaps a United States working day without one side moving. - Market depth matters only if you need many parallel teams or a rare specialism. - Run the same paid discovery with two suppliers before committing to either. ## Terms used in this comparison Offshore vocabulary is used loosely in sales conversations, and two suppliers can describe very different arrangements with the same word. These are the meanings used throughout this guide. - Offshore — a supplier in a distant country and time zone, usually chosen for cost and capacity. - Nearshore — a supplier within a few hours of your own working day, usually in a neighbouring region. - Offshore development centre — a team in the supplier's office working only on your product, under your direction. - Build-operate-transfer — the supplier recruits and runs a team that you later take over as your own legal entity or staff. - Staff augmentation — individual engineers join your team and your process; you manage the work. - Project outsourcing — the supplier owns scope, estimate and delivery, and reports results rather than hours. - Overlap window — the hours per day in which both sides are at work and a question can be answered without waiting a night. ## What actually differs between the four Four things vary by country in a way the supplier cannot change: the clock, the size and shape of the local industry, the legal and tax environment your contract meets, and the pool of people the supplier recruits from. Everything else that matters, including engineering judgement, communication, quality control and honesty about risk, varies far more between two firms in one city than between the four countries. That is why a shortlist built from country rankings tends to perform worse than a shortlist built from two or three named suppliers you have tested with real work. Use the country to narrow the field, not to pick the winner. ## The four destinations side by side Each line below compares one dimension across all four destinations. Rates are deliberately absent: published country averages mix junior and senior work, agency and freelance supply, and currencies that move, so they mislead more often than they help. Ask two suppliers for a priced proposal against the same written scope instead. - Time zone — Sri Lanka and India are UTC+5:30, Vietnam UTC+7, the Philippines UTC+8. None of the four observes daylight saving, so the gap to your own clock changes when yours changes, not when theirs does. - Industry size — India is the largest technology services market of the four by a wide margin, the Philippines and Vietnam are large and growing, and Sri Lanka is the smallest. - Supplier mix — India spans one-person shops to listed firms employing tens of thousands; Sri Lanka and Vietnam are weighted towards small and mid-sized firms; the Philippines has deep business-process and support operations alongside its engineering firms. - Specialist depth — a rare platform, regulated-industry or large parallel-team requirement is most likely to be met in India; the other three are stronger for one or two focused product teams. - English in delivery roles — English is a normal working language in Indian, Sri Lankan and Philippine delivery teams, and more variable in Vietnam outside client-facing roles. Verify this with the engineers on your project, never by country. - Overlap with the United Kingdom and Europe — Sri Lanka and India cover a European morning and part of the afternoon, Vietnam and the Philippines only the early morning. - Overlap with Australia and East Asia — the Philippines and Vietnam are two to three hours behind Sydney, Sri Lanka and India four and a half to five and a half. - Overlap with the United States — none of the four overlaps a United States working day. Someone works outside their own daylight, or the handover becomes asynchronous by design. - Data protection law — India has a Digital Personal Data Protection Act, Sri Lanka a Personal Data Protection Act, the Philippines a Data Privacy Act, and Vietnam a personal data protection decree. Confirm the current text and enforcement status before relying on any of them. - Contracting — cross-border agreements in all four are commonly written under English, Singapore or the client's own law with arbitration. Choose the forum deliberately; local enforcement is slow everywhere. ## The time zone is the decision you live with daily Market depth is a procurement question you answer once. The overlap window is a question you answer every working day for the life of the engagement, and it quietly sets how your team works. With four or more shared hours you can hold a normal conversation, review work live and unblock people the same day. With one or two, every question costs a night, and the engagement only works if written handovers, clear acceptance conditions and genuine autonomy are built in from the start. A working day of 09:00 to 18:00 in Colombo or Bengaluru is 03:30 to 12:30 in London in winter, so about three and a half hours of a London working day are shared, and about four and a half once British Summer Time starts. The same day in Hanoi or Manila shares roughly one to two hours with London, and six or more with Singapore and Sydney. ## What the country does not tell you Attrition, seniority on your account, how a supplier behaves when an estimate is wrong, whether the people in the pitch are the people who write the code, and whether you will own what is built are all supplier facts. They vary enormously inside every one of these four markets, and they are the facts that decide whether a project succeeds. Two of these carry more weight than buyers expect. The first is where your project ranks by revenue inside the supplier: a small account at a large firm gets the attention a small account gets. The second is who holds the knowledge, because a team with one irreplaceable engineer is a risk in any country. - Will the engineers in the proposal be on the project in month three? - What is the supplier's turnover on long-running accounts? - Where would our account sit in their revenue, and who is our escalation? - Who owns the repository, the cloud account and the deployment pipeline? - What happens to the work if the relationship ends next quarter? ## A decision rule Apply these in order and stop at the first one that matches your situation. - Rule 1: if you need several parallel teams, a rare specialism or a regulated-industry track record, start in India, because only its market reliably has that depth. - Rule 2: if your own working day is European, British, African or Gulf, prefer UTC+5:30 and shortlist in Sri Lanka or India. - Rule 3: if your working day is Australian, Singaporean or East Asian, prefer the Philippines or Vietnam. - Rule 4: if your working day is North American, accept that the model is asynchronous and choose the supplier with the best written communication, not the smallest time gap. - Rule 5: if continuity matters more than scale, which is usually true for a single long-lived product, weight team stability and seniority on your account above every country-level factor. - Rule 6: if two destinations still look equivalent, run the same paid discovery with one supplier in each and decide on the questions they ask, not the documents they produce. ## Due diligence that applies in every country The checks below do not change with the destination. Run them identically on every supplier you shortlist, and treat a refusal to answer as an answer. - A named, verifiable project close to your own problem - A conversation with an engineer who will do the work - Written assumptions, exclusions and acceptance conditions - Client-controlled repositories, cloud accounts and secrets - A security and data-handling answer proportionate to your data - An exit clause with handover obligations and a support window ## Questions ### Is Sri Lanka or India better for offshore software development? They share a time zone, so the choice is about market depth against account attention. India has far more suppliers and the only reliable depth for rare specialisms or many parallel teams. Sri Lanka is a smaller market of mostly small and mid-sized firms, where a modest project is more likely to be a significant account. Compare named suppliers, not the two countries. ### Which offshore country works best with United States hours? None of Sri Lanka, India, Vietnam or the Philippines overlaps a United States working day. If you need live daytime cover, look at Latin America instead. If asynchronous delivery is acceptable, choose on written communication, clear acceptance conditions and autonomy rather than on the size of the time gap. ### Why does this guide not compare hourly rates by country? Published country averages mix junior and senior work, freelance and agency supply, and currencies that move, so two suppliers in one city can sit either side of their national figure. A priced proposal from two suppliers against the same written scope tells you more than any country average. ### Does the offshore country affect who owns the code? Ownership comes from the contract, not the country. State in writing that the client owns source code, designs, infrastructure definitions and pipelines, hold the repositories and cloud accounts in client-controlled accounts from day one, and agree the law and forum for disputes deliberately. ## Related - [Explore our software development services](https://codesagelabs.com/services) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/offshore-software-development-sri-lanka-vs-india](https://codesagelabs.com/resources/offshore-software-development-sri-lanka-vs-india) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "How Custom Software Is Priced" description: "What drives the cost of custom software, how a supplier builds an estimate, how the pricing models differ and how to compare two quotes that look nothing alike." url: "https://codesagelabs.com/resources/how-custom-software-is-priced" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # How Custom Software Is Priced By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. This guide explains how software prices are constructed and what moves them. It publishes no rates, ours or anyone else's, because a rate detached from scope, seniority and written assumptions is not information. What you can take from it is the ability to read an estimate, see what a supplier has assumed, and compare two proposals that arrived in different shapes. ## Key takeaways - Price is effort multiplied by rate, plus whatever the supplier is charging for risk. - Integrations, data migration and non-functional requirements move cost more than feature count. - The pricing model decides who carries scope risk; it does not change the work. - An estimate without written assumptions and exclusions cannot be compared with anything. - Decision speed on the buyer's side is a real and frequently underestimated cost driver. ## Terms used in this guide Commercial conversations go wrong when the two sides use the same words differently. Fix the vocabulary before discussing numbers. - Estimate — a supplier's forecast of effort, correct only against the assumptions attached to it. - Quote — a price the supplier is willing to be held to, which therefore contains contingency. - Budget — what you can spend, which is yours to state and should shape scope rather than be guessed at. - Day rate — the price of one person for one day; meaningless without the seniority and the role it covers. - Blended rate — one averaged rate across a mixed team, which hides who actually does the work. - Contingency — money added for the parts nobody can see yet; present in every fixed price whether or not it is shown. - Discovery — a short paid phase that converts unknowns into a scope worth pricing. - Change request — a priced amendment to a fixed scope, the mechanism that keeps a fixed price honest. - Non-functional requirements — uptime, performance, security, accessibility and recovery targets, which are work even though no user sees them as features. ## What you are actually buying Every price in this market is effort multiplied by a rate, plus a risk premium. Effort is engineering hours, plus the design, testing, review, deployment, documentation and project work that comes with them. The rate reflects seniority, location and the supplier's own costs. The risk premium is the part suppliers rarely itemise: the less certain the scope, the larger it is, and in a fixed price it is invisible. This is why two quotes for the same brief can differ by a multiple without either being dishonest. One may have assumed your data is clean, one integration is enough and you will supply content on time. The other may have assumed none of those things. The difference is in the assumptions, not in the arithmetic. ## The cost drivers, in rough order of weight Buyers usually expect feature count to dominate. In practice it rarely does. The drivers below reorder most estimates, and the first four are responsible for most of the surprises. - Integrations — each external system adds a contract, failure handling, credentials, reconciliation and a dependency on somebody else's release schedule. - Data migration — legacy data is almost never as clean as reported, and the cleaning, mapping and rehearsal is often larger than the feature it feeds. - Non-functional requirements — high uptime, audit trails, encryption, performance targets and accessibility obligations are engineering work, not settings. - Existing code quality — building inside an undocumented system with no tests costs more than building the same thing fresh. - Roles and permissions — every additional user type multiplies the paths that must be built, tested and secured. - Platform count — web, iOS and Android are three delivery surfaces, with three sets of testing and release work. - Design novelty — a system built from an existing component library costs less than one designed screen by screen. - Regulatory and review steps — approvals, audits and formal documentation add elapsed time and effort regardless of difficulty. - Decision latency on your side — a team waiting four days for an answer is still being paid; slow approvals are one of the most expensive habits a buyer has. - Environments, deployment and monitoring — real systems need staging, pipelines, backups and alerts, and these are commonly missing from a cheap quote. - Support after launch — the warranty window, response times and who fixes defects is a priced commitment, not goodwill. ## The pricing models side by side Five models cover almost everything you will be offered. Each line gives who carries scope risk, where the model fits, how change is handled and what to watch for. - Fixed price — supplier carries scope risk; fits genuinely bounded work with written acceptance conditions; change goes through a priced change request; watch for hidden contingency and a long exclusions list. - Time and materials — buyer carries scope risk; fits work whose direction will change; change is simply the next priority; watch for an open-ended total and thin reporting. - Capped time and materials — risk is shared above the cap; fits mostly-clear scope with some unknowns; change is reprioritised under the cap; watch for the cap quietly becoming the target. - Monthly retainer or dedicated team — buyer carries scope risk, supplier carries staffing risk; fits continuous product work; change is handled in the backlog; watch for paying for capacity you are not keeping busy. - Milestone or outcome-based — risk follows whoever controls the outcome; fits measurable results inside the supplier's control; change is renegotiated per milestone; watch for outcomes that actually depend on your users, your data or your marketing. ## How an honest estimate is built A usable estimate is built bottom-up from a list of work items, not top-down from a number the buyer mentioned. It carries a range rather than a point, and the range narrows as unknowns are closed. It names its assumptions, states what is excluded, and says which questions would change it most. A supplier who identifies the three riskiest unknowns and proposes a short paid investigation is usually safer than one who prices unclear work to the day. Confidence is not accuracy, and an estimate presented without a range is a marketing document. - A work breakdown you can read, not a single figure - A range, with the reason the range is that wide - Explicit assumptions about data, content, integrations and approvals - An exclusions list, including what happens after launch - The acceptance conditions that define done - What the supplier would need to know to tighten the number ## Comparing two quotes that look different Normalise before comparing. Put both proposals against the same scope and the same list of assumptions, and most of the apparent difference will turn out to be items one supplier included and the other left out. - Is discovery priced in, priced separately or absent? - Does the number include design, testing, deployment and documentation? - Is data migration in scope, and whose job is the cleaning? - Which integrations are included, and at what level of failure handling? - What is the warranty period and what counts as a defect within it? - Who pays for third-party services, licences and infrastructure? - What is the change-request process and how is it priced? - What is assumed about your availability for decisions and content? ## A decision rule for choosing the model Apply these in order and stop at the first that matches. - Rule 1: if you cannot write the acceptance conditions today, buy a short paid discovery first and price the build afterwards. - Rule 2: if scope and acceptance are written, bounded and unlikely to move, use fixed price. - Rule 3: if the scope is mostly clear but two or three unknowns remain, use capped time and materials and spend the cap on the unknowns first. - Rule 4: if the product will keep changing because you are learning from users, use time and materials or a monthly team, with visible priorities and burn reporting. - Rule 5: if the work is continuous and indefinite, use a retainer sized to the work you can actually feed it, not to the team you would like to have. - Rule 6: only accept outcome-based pricing when the outcome is measurable, attributable and inside the supplier's control; otherwise it becomes a dispute. ## What should never be in a price A few charges indicate a supplier whose commercial model depends on you being unable to leave. Treat each of them as a reason to renegotiate before signing. - A fee to receive the source code of software you paid to have built - A licence back to you for your own commissioned work - A charge for access to the repository, cloud account or pipeline - Handover priced as a separate project at the end of the relationship - Mandatory hosting with the supplier as a condition of ownership ## Questions ### How much does custom software cost? There is no useful single figure, which is why this guide gives none. The same brief can differ by a multiple depending on integrations, data migration, uptime and security requirements, platform count and the state of any existing code. Ask two suppliers to price the same written scope with assumptions attached, and compare those. ### Why will a supplier not give a price on the first call? Because a number given before the integrations, data and acceptance conditions are known is either padded heavily or will be revised later. A supplier who proposes a short paid discovery is converting unknowns into something that can be priced honestly. ### Is a fixed price cheaper than time and materials? Usually not. A fixed price includes contingency for risk the supplier cannot see, and you pay that contingency whether or not the risk occurs. Fixed price buys budget certainty, not a lower total. ### Should I tell a supplier my budget? Yes, if you have one. A budget is a constraint that shapes scope, and withholding it usually produces a proposal you cannot buy. It is not an invitation to spend it all; a credible supplier will tell you what fits and what does not. ## Related - [Explore our software development services](https://codesagelabs.com/services) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/how-custom-software-is-priced](https://codesagelabs.com/resources/how-custom-software-is-priced) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Fixed Price vs Time and Materials" description: "How fixed-price, time-and-materials and capped contracts differ: who carries scope risk, how change is handled, how each fails and which to use for a given project." url: "https://codesagelabs.com/resources/fixed-price-vs-time-and-materials" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Fixed Price vs Time and Materials By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. Fixed price and time and materials do not change the work, the team or the amount of engineering required. They change who absorbs the gap between what was imagined and what turns out to be true. Choosing between them is a question about how much of your scope is genuinely known, and answering it honestly is more useful than arguing about which model is safer in general. ## Key takeaways - The model allocates scope risk; it does not reduce the work or the uncertainty. - Fixed price buys budget certainty and pays for it in contingency and change requests. - Time and materials buys flexibility and requires you to manage priorities. - A cap shares the risk but only works with real burn reporting and stop conditions. - Mixing models by phase is normal: discovery and build do not need the same contract. ## Terms used in this guide These words are used inconsistently across proposals. The definitions below are the ones used here. - Fixed price — an agreed total for an agreed scope, with changes handled by priced amendment. - Time and materials — payment for effort actually spent, at agreed rates, against a prioritised backlog. - Capped time and materials — time and materials with an upper limit, above which the supplier absorbs the cost or work stops. - Scope risk — the chance that delivering the agreed result takes more effort than was assumed. - Burn — effort consumed so far, usually reported against a forecast. - Stop condition — a written trigger, such as reaching a percentage of the cap, that forces a decision rather than a surprise. - Acceptance conditions — the written tests that decide whether a deliverable counts as done. - Retention — a share of the price held back until acceptance or the end of a warranty period. ## What each model actually does Under a fixed price the supplier promises a result for a number, so the supplier owns the gap between the estimate and reality. To survive that promise the supplier adds contingency, scopes defensively and must police change, because every unplanned item comes out of their margin. None of this is bad faith; it is the only rational response to carrying the risk. Under time and materials you own the gap. The supplier has no reason to pad the estimate or to argue about a small change, but nobody except you is holding the total down. The protection is not contractual, it is operational: visible priorities, regular forecasts and a willingness to cut scope when the forecast moves. ## The two models side by side Each line compares one dimension across both models, with the capped variant noted where it differs. - Scope risk — fixed price: supplier. Time and materials: buyer. Capped: supplier above the cap. - Price certainty — fixed price: high, for the agreed scope only. Time and materials: low without active management. Capped: bounded at the top. - Estimate incentive — fixed price: estimate high to stay safe. Time and materials: estimate realistically, since there is nothing to hide. Capped: estimate near the cap. - Handling change — fixed price: a priced change request each time. Time and materials: reprioritise the backlog. Capped: reprioritise under the cap. - Buyer effort required — fixed price: heavy up front, writing scope and acceptance. Time and materials: steady throughout, owning priorities. Capped: both. - Supplier behaviour under pressure — fixed price: defend scope and reduce quality that is not in the acceptance conditions. Time and materials: keep working unless you intervene. - Typical failure — fixed price: an adversarial change-request war, or a thin delivery that technically passes. Time and materials: an unbounded total and a project with no edge. - Cash-flow shape — fixed price: milestone payments against deliverables. Time and materials: monthly against effort. - Fit for discovery — fixed price: poor, because the scope is what you are trying to discover. Time and materials: good, bounded by a short timebox. - Fit for ongoing product work — fixed price: poor, because every iteration is an amendment. Time and materials: good. - Fit for a well-specified replacement or integration — fixed price: good. Time and materials: workable but gives away your certainty. ## Where fixed price goes wrong Fixed price fails when it is used to buy certainty that the scope cannot support. The contract then makes every discovery a negotiation: the supplier must defend margin, you must argue that an obvious requirement was implied, and both sides spend attention on the contract rather than on the software. The second failure is quieter. Quality that is not written into the acceptance conditions is where a squeezed fixed price gives way first, and it is usually tests, error handling, documentation, deployment and the non-functional requirements nobody wrote down. ## Where time and materials goes wrong Time and materials fails when nobody on the buyer's side owns priorities. Without a decision-maker the backlog grows, the team stays busy, and six months later the money is gone and the product has no defined edge. The supplier was working the whole time, which is precisely why the problem is invisible until the invoice total is read as a total. It also fails when reporting is thin. Hours by person is not reporting. A forecast to completion, revised when it moves, is. ## Making each model safe Both models work when the known weakness is covered deliberately. Fixed price needs its scope written and its change process agreed before signature. Time and materials needs its visibility and its brakes installed before the first sprint, not after the first surprise. - Fixed price: written acceptance conditions for every deliverable - Fixed price: an assumptions and exclusions list attached to the price - Fixed price: a change-request process with a published rate and a turnaround time - Fixed price: milestones small enough that a bad one is recoverable - Time and materials: one named person who owns priorities - Time and materials: a forecast to completion, revised every cycle - Time and materials: a budget checkpoint that triggers a scope decision - Time and materials: working software reviewable at the end of each cycle ## A decision rule Apply these in order and stop at the first that matches. - Rule 1: if you cannot write the acceptance conditions today, do not sign a fixed price for the build. Buy a timeboxed discovery instead. - Rule 2: if scope, data, integrations and acceptance are written and stable, take the fixed price. - Rule 3: if two or three unknowns remain and the rest is clear, use a capped model and spend the first weeks closing those unknowns. - Rule 4: if you expect to change direction based on what users do, use time and materials and accept the obligation to manage it. - Rule 5: if you cannot give the project a decision-maker with real availability, do not use time and materials, because the model depends on one. - Rule 6: if the project has both a bounded part and an open-ended part, contract them separately rather than forcing one model across both. ## Questions ### Is fixed price safer than time and materials? Only when the scope is genuinely known and the acceptance conditions are written. Applied to uncertain work it shifts risk onto the supplier, who prices for it and then has to defend the boundary, which is how a project becomes a change-request negotiation. ### How do I stop a time-and-materials project running away? Appoint one person who owns priorities, require a forecast to completion rather than a list of hours, review working software every cycle, and set a budget checkpoint that forces a scope decision before the money runs out. ### What is a capped time-and-materials contract? Time and materials with an agreed upper limit. You pay only for effort spent, the supplier absorbs cost above the cap or work stops there, and change is handled by reprioritising under the cap. It suits scope that is mostly clear but not fully resolved. ### Can one project use both models? Yes, and it is often the best answer. A timeboxed discovery on time and materials, followed by a fixed price for the part that discovery made certain, puts each model where it works. ## Related - [Explore our software development services](https://codesagelabs.com/services) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/fixed-price-vs-time-and-materials](https://codesagelabs.com/resources/fixed-price-vs-time-and-materials) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Engagement Models Compared: Staff Augmentation, Project Outsourcing and White-Label" description: "How staff augmentation, project outsourcing and white-label delivery differ on management, estimates, risk, client contact and quality control, with a rule for choosing." url: "https://codesagelabs.com/resources/engagement-models-compared" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Engagement Models Compared: Staff Augmentation, Project Outsourcing and White-Label By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. Three arrangements dominate external software delivery, and the difference between them is not the engineers. It is who manages the work, who owns the estimate, who carries the risk when it slips and whose name is in front of the end client. Choosing the wrong one produces a predictable failure: a team nobody is directing, a supplier owning decisions you needed to own, or an agency discovering it has resold a promise it cannot see. ## Key takeaways - Staff augmentation gives you capacity; you keep management and delivery risk. - Project outsourcing transfers delivery risk and with it a real share of control. - White-label is project outsourcing plus an agreed position in front of the end client. - The model decides who is accountable when a date moves; agree that before signing. - Agencies should test a partner on scoping behaviour, not only on finished work. ## Terms used in this comparison The three names are used loosely, and some suppliers sell one and deliver another. These are the working definitions. - Staff augmentation — individual engineers join your team, your process and your tools; you direct the work and own the result. - Project outsourcing — the supplier takes a defined outcome, owns the estimate and the delivery plan, and reports progress against it. - White-label delivery — project outsourcing where the supplier works behind the agency's brand and the agency holds the client relationship. - Dedicated team — a middle form: a stable group working only on your product, directed by you but managed by the supplier. - Managed delivery — the supplier supplies the process as well as the people, including its own lead and quality controls. - Delivery risk — the exposure when the work takes longer, costs more or does not meet acceptance. - Brand boundary — the written rule about who the end client sees, emails and meets. ## What each model is for Staff augmentation solves a capacity problem. You know what to build and how you build it; you do not have enough people. The supplier's value is finding and keeping good engineers, and almost nothing else. If your own process is weak, augmentation makes it weaker, because you have added people to a system that was not directing the ones it had. Project outsourcing solves a capability or attention problem. You need an outcome and do not intend to manage its production. The supplier's value is the whole delivery system: scoping, estimating, building, testing and shipping. You give up day-to-day control, which is the point, and you keep acceptance. White-label is project outsourcing with the brand boundary written down. It exists because the agency's client bought from the agency and should continue to experience the agency. The engineering obligations are the same; the additional obligations are confidentiality, communication discipline and never contradicting the agency in front of its client. ## The three models side by side Each line compares one dimension across all three. - Who manages day-to-day work — augmentation: you. Outsourcing: the supplier. White-label: the supplier, reporting to the agency. - Who owns the estimate — augmentation: you, since you set the scope. Outsourcing and white-label: the supplier. - Who carries delivery risk — augmentation: you. Outsourcing: the supplier, up to the agreed scope. White-label: the supplier to the agency, the agency to the end client. - Who talks to the end client — augmentation: not applicable. Outsourcing: usually the supplier, directly. White-label: the agency, unless it approves otherwise in writing. - How quality is controlled — augmentation: your reviews, your tests, your standard. Outsourcing and white-label: the supplier's definition of done, which you should read before signing. - Knowledge retention — augmentation: strong, because the work happens inside your process. Outsourcing and white-label: depends entirely on documentation and handover terms. - Speed to start — augmentation: fast once people are available, slow to become productive. Outsourcing and white-label: slower to contract, faster to a shipped outcome. - Cost shape — augmentation: per person per month, continuous. Outsourcing: per project or milestone. White-label: per project, with the agency's margin on top. - What it looks like when it fails — augmentation: engineers waiting for direction. Outsourcing: a demo that meets the letter of the scope and misses the point. White-label: the agency finding out about a slip from its own client. - Best fit — augmentation: a strong internal team short of hands. Outsourcing: a defined outcome you do not want to manage. White-label: an agency selling work it does not build. ## The failure mode of each, and the fix Each model fails in its own way, and each failure has a cheap preventative that is almost always skipped at contract stage. - Augmentation without direction — fix: name the internal owner of each engineer's priorities before they start. - Augmentation used to avoid hiring permanently — fix: accept it as a long-term cost or plan the transfer of knowledge deliberately. - Outsourcing with vague acceptance — fix: write the acceptance conditions before the price is agreed. - Outsourcing that hollows out your own team — fix: keep architecture and product decisions in-house even when building is outside. - White-label with an unclear brand boundary — fix: write down who may email, call or appear in front of the end client. - White-label with no visibility for the agency — fix: the agency attends demos and holds repository access throughout, not at the end. ## What an agency should test before reselling a partner An agency carries the end-client relationship, so a partner's failure is the agency's failure. Finished work in a portfolio proves the partner shipped something; it does not predict how they behave when a brief is ambiguous, which is the situation an agency actually resells. - Give a real brief and judge the questions, not the turnaround - Ask what they would refuse to estimate without more information - Read their definition of done and see whether tests and deployment are in it - Meet the engineer who would lead the work - Agree the escalation route and the response time before the first project - Run a small paid engagement with genuine ambiguity in it ## A decision rule Apply these in order and stop at the first that matches. - Rule 1: if you have a working delivery process and a named person to direct the work, use staff augmentation. - Rule 2: if you have no one available to direct engineers daily, do not use staff augmentation under any circumstances; it will fail quietly. - Rule 3: if you need an outcome rather than capacity, and you can write what acceptance means, use project outsourcing. - Rule 4: if you are an agency whose client bought from you, use white-label and write the brand boundary into the contract. - Rule 5: if the work is long-lived product development rather than a bounded project, use a dedicated team with your own product decisions kept in-house. - Rule 6: whichever you choose, keep repositories, cloud accounts and secrets under your control from the first day, because the model can change and ownership should not. ## What to write down whichever model you choose Most disputes in all three models come from the same short list of things nobody wrote down. Settle them before work starts, when they are still cheap. - Who sets priorities and who accepts the work - What done means, including tests, deployment and documentation - Who may contact the end client and in whose name - How change is requested, priced and recorded - Who owns code, infrastructure, designs and accounts - How defects after launch are separated from new work - How the engagement ends and what is handed over ## Questions ### What is the difference between staff augmentation and outsourcing? Staff augmentation adds engineers to your team while you keep management, process and delivery risk. Outsourcing transfers a defined outcome to the supplier, who owns the estimate, the plan and the risk of overrun, and reports against acceptance conditions instead of hours. ### Is white-label development the same as outsourcing? The engineering obligations are the same. White-label adds a written brand boundary: the supplier works behind the agency's name, the agency keeps the client relationship, and the supplier does not contact or contradict the end client without approval. ### Which engagement model is cheapest? None is reliably cheapest, because they buy different things. Augmentation looks cheapest per person and costs most when nobody directs the work. Outsourcing includes the supplier's management and risk in the price. White-label adds the agency's margin on top of an outsourced delivery. ### Can an engagement model change mid-project? Yes, and it often should, for example moving from an outsourced first release to augmentation once you have your own team. Plan the transfer of knowledge, documentation and access at the point of the change rather than afterwards. ## Related - [See our agency partnership model](https://codesagelabs.com/agencies) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/engagement-models-compared](https://codesagelabs.com/resources/engagement-models-compared) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "In-House Team vs Outsourced Development" description: "A comparison of building an in-house engineering team against outsourcing development: real cost shape, speed to start, knowledge retention, control and risk." url: "https://codesagelabs.com/resources/in-house-vs-outsourced-development" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # In-House Team vs Outsourced Development By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. The in-house versus outsourced argument is usually conducted as a comparison of a salary against a day rate, which is the one comparison that cannot be made directly. An employee is a fixed cost with recruitment, management, equipment, idle time and attrition attached. A supplier is a variable cost with a margin and a knowledge-retention problem attached. The real question is which risks you would rather hold. ## Key takeaways - Comparing a salary with a day rate omits most of what an in-house team costs. - In-house wins on retained knowledge and availability; outsourcing wins on speed and flexibility. - Hiring risk is the largest hidden cost of going in-house for a first team. - Most organisations end up hybrid; the question is which parts stay inside. - Keep product decisions and architecture in-house even when building is outside. ## Terms used in this guide The comparison only works once these are distinguished. - In-house — engineers employed by you, working on your systems under your management. - Outsourced — an external supplier delivering work under a contract, by project or by team. - Hybrid — a small permanent core that owns decisions, with external capacity for build work. - Fully loaded cost — salary plus employer taxes, benefits, equipment, software, workspace, recruitment and management time. - Ramp time — the weeks before a new engineer is productive in your codebase and domain. - Bench — paid capacity with no current work, which in-house teams carry and suppliers absorb. - Bus factor — the number of people who can leave before the system becomes unmaintainable. - Tribal knowledge — what the team knows but has never written down. ## The comparison is not cost per hour An in-house engineer costs their fully loaded cost whether or not there is work this month, plus the recruitment effort to find them, plus the management attention to keep them, plus the ramp time before they are useful, plus the risk that they leave and take the context with them. A supplier costs more per day and nothing in the months you do not use them. This means the honest comparison depends on how continuous your work is. Continuous work favours employment, because you are paying for capacity you are definitely using and keeping the knowledge. Intermittent or spiky work favours a supplier, because the alternative is paying for a bench. Neither statement is about rates. ## The two options side by side Each line compares one dimension across both. - Cost shape — in-house: fixed and continuous. Outsourced: variable, paid per project or per month of use. - Speed to start — in-house: recruitment plus notice period plus ramp. Outsourced: contracting plus ramp, usually far shorter. - Speed to stop — in-house: slow and personally costly. Outsourced: contractual notice. - Knowledge retention — in-house: stays, as long as people stay. Outsourced: leaves with the supplier unless documentation and handover are enforced. - Control of priorities — in-house: direct and immediate. Outsourced: through a contract and a backlog. - Domain depth — in-house: accumulates year on year. Outsourced: bought in and rebuilt at each change of supplier. - Breadth of skills — in-house: limited to who you employ. Outsourced: a supplier can move specialists in for a phase. - Hiring risk — in-house: high and yours, especially for a first technical hire. Outsourced: the supplier's problem. - Quality control — in-house: your standard, applied continuously. Outsourced: contractual, through acceptance conditions. - Security and access — in-house: simpler, with fewer external parties. Outsourced: workable but requires named accounts, least privilege and offboarding. - Continuity risk — in-house: concentrated in a few individuals. Outsourced: concentrated in one commercial relationship. ## When in-house is the right answer Build in-house when the software is the business, when the work is continuous enough to keep people busy, and when the domain knowledge is the thing that compounds. A product company whose engineers understand ten years of customer behaviour has something no supplier can be contracted into. There is also a threshold question of your own capability. Hiring engineers well requires someone who can evaluate engineers. If your first technical hire is also your only technical judgement, the hiring risk is larger than it looks, and a short outsourced engagement with a trusted supplier is a common way to bridge it. ## When outsourcing is the right answer Outsource when the work is bounded, intermittent or outside your core, when speed to a first release matters more than long-term ownership of the skill, and when you need a specialism you would not employ full time. An integration, a modernisation phase, a mobile application for a business that does not otherwise build software: all of these are work that will not keep a permanent team busy afterwards. Outsourcing is also the right answer when a date is fixed and your hiring pipeline cannot meet it. Starting a permanent hiring round to meet a deadline three months away is a plan that fails on arithmetic. ## The hybrid that usually works Most organisations that outsource successfully keep a small internal core and buy capacity around it. The core is not a management layer; it is the people who hold product decisions, architecture and operational knowledge, so that a change of supplier is an inconvenience rather than a catastrophe. - One internal owner of product decisions and priorities - At least one internal engineer who can read and review the code - Architecture decisions recorded internally, not in supplier documents - Repositories, cloud accounts and secrets in your own accounts - Documentation delivered continuously as a condition of payment - An annual exercise in deploying and changing the system without the supplier ## A decision rule Apply these in order and stop at the first that matches. - Rule 1: if the software is the product you sell, build the core in-house, whatever else you outsource. - Rule 2: if the work will not keep a permanent engineer busy for at least a year, outsource it. - Rule 3: if you have no one who can evaluate engineers, do not make your first technical hire blind; buy a bounded engagement first and hire with that experience. - Rule 4: if a fixed external date is closer than your hiring pipeline, outsource for the date and hire behind it if the work continues. - Rule 5: if the work needs a specialism for one phase only, outsource that phase rather than employing it. - Rule 6: whatever the mix, keep product decisions, architecture records and account ownership inside; those are the things that make the next decision reversible. ## How to outsource without losing the knowledge The strongest argument against outsourcing is that the understanding leaves with the supplier. That outcome is not inevitable; it is the result of treating documentation and ownership as end-of-project activities. Make them conditions of ongoing payment and the argument largely disappears. - Architecture decision records written as decisions are made - A runbook that your own staff have followed at least once - Your engineers present in code review, even if they do not write code - Demos of working software, not status documents - Credentials and infrastructure held by you throughout - A rehearsed handover before the relationship needs to end ## Questions ### Is outsourcing cheaper than hiring in-house? Per day, almost never. Over a year it depends on how continuous the work is. A permanent engineer costs their fully loaded cost every month including the quiet ones; a supplier costs nothing in a month you do not use them. Continuous work favours employment, intermittent work favours a supplier. ### When should a company start building an in-house team? When the work becomes continuous, when the domain knowledge is what differentiates the product, and when there is someone who can evaluate and manage engineers. Until all three are true, a hybrid with a small internal core is usually safer. ### What is the biggest risk of outsourcing development? Losing the understanding of your own system. It is preventable: keep ownership of repositories and accounts, require documentation and architecture records during delivery rather than at the end, and keep at least one internal person who can read the code. ### Can we outsource and hire at the same time? Yes, and it is a common way to bridge a deadline. Have the supplier deliver against the date while your first hires onboard alongside them, and plan the handover of knowledge explicitly rather than hoping it transfers by proximity. ## Related - [Explore our software development services](https://codesagelabs.com/services) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/in-house-vs-outsourced-development](https://codesagelabs.com/resources/in-house-vs-outsourced-development) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Working With a Sri Lankan Development Team" description: "Time zones and overlap hours, the working week and holiday calendar, language, contracting, payment and data questions when your development team is in Sri Lanka." url: "https://codesagelabs.com/resources/working-with-a-sri-lankan-development-team" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Working With a Sri Lankan Development Team By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. This is the practical detail a buyer needs after deciding to work with a team in Sri Lanka: how the clock lines up with yours, what the working week and the holiday calendar look like, how written communication usually runs, and which contracting, payment and data questions to settle in the first week. Code Sage Labs is based in Colombo, so this is written from the inside; the arrangements described are ordinary for the market, not specific to us. ## Key takeaways - Sri Lanka is UTC+5:30 year-round and does not observe daylight saving. - A Colombo day overlaps Europe and the Gulf well, Australia partly, and the Americas not at all. - The holiday calendar includes a Poya day each month and the dates move each year. - English is the normal working language of the local software industry. - Settle currency, payment route, data terms and the governing law in week one. ## Terms used in this guide A few of these are local and the rest are cross-border contracting vocabulary. - UTC+5:30 — Sri Lanka Standard Time, fixed all year, with no daylight saving adjustment. - Overlap window — the hours in which both your working day and the team's are open. - Poya day — the monthly full-moon public holiday in Sri Lanka; the date moves with the lunar calendar. - Asynchronous handover — a written end-of-day summary that lets the next time zone continue without a meeting. - SWIFT transfer — the usual international bank route for paying a Sri Lankan supplier. - Standard contractual clauses — the data-transfer terms a European or British client typically attaches when a processor is outside their jurisdiction. - Governing law and forum — the law the contract is read under and where a dispute would be heard; both are chosen, not inherited from the supplier's location. ## The time zone, concretely Sri Lanka sits at UTC+5:30 and stays there. Your own clock is the one that moves, so the gap changes twice a year if you observe daylight saving and never otherwise. The lines below take an ordinary Colombo working day of 09:00 to 18:00 and give the approximate shared hours with a 09:00 to 17:00 or 18:00 day elsewhere. - London — about three and a half shared hours in winter, about four and a half during British Summer Time. - Berlin, Paris, Amsterdam — about four and a half shared hours in winter, five and a half in summer. - Dubai and the Gulf — around seven shared hours; effectively a normal working relationship. - Singapore and Hong Kong — around six and a half shared hours, weighted to the Colombo afternoon. - Sydney and Melbourne — about three and a half shared hours, falling to two and a half under daylight saving, in the Colombo afternoon. - New York and Toronto — no shared hours within normal working days; collaboration is asynchronous or scheduled outside one side's day. - San Francisco — no shared hours; the practical pattern is a written handover each way. ## What the overlap means in practice Three to five shared hours is enough for a normal working relationship if the day is arranged around it. Put the standing call, reviews and anything needing a decision inside the window, and leave deep work outside it. The common mistake is to spread meetings across the window until it is full, which removes the only hours in which questions can be answered quickly. For the Americas, do not try to fix the clock by asking a Colombo team to work nights permanently. It holds for a few weeks and then the good engineers leave. The arrangement that lasts is a genuine asynchronous one: written end-of-day handovers, acceptance conditions clear enough to unblock without a call, and one scheduled overlap meeting a week at a time that is inconvenient for both sides equally. ## The working week and the holiday calendar The software industry works Monday to Friday. The public holiday calendar is longer than in most Western countries and includes a Poya day every month, when the full moon falls, plus religious and national holidays across several traditions. The dates of many of them move each year, and some are confirmed only a few months ahead. None of this is a problem if it is planned, and it is a recurring irritation if it is not. Ask for the supplier's holiday calendar at kickoff, put it in the shared project calendar, and plan releases and milestones around it rather than discovering a holiday on the morning of a deadline. - Request the year's holiday calendar in the first week - Agree cover arrangements for any holiday that lands on a release date - Check how April's festival period is handled, as it is a longer break than most - Agree in advance what counts as an emergency and who responds - Note that your holidays are equally invisible to them; share both calendars ## Language and written communication English is the working language of the Sri Lankan software industry: documentation, code, tickets and client meetings are normally in English, and Sinhala and Tamil are the languages spoken at home and between colleagues. For a client this means written communication is rarely the obstacle, though accents and speaking pace take a short adjustment on both sides, as they do in any cross-border team. Judge this per team rather than per country, as with any destination. The useful test is not a sales call, which is rehearsed, but a written one: ask for a short written analysis of an ambiguous requirement from the engineer who would do the work, and read how they handle the ambiguity as well as the language. ## Contracting, payment and data Cross-border agreements with Sri Lankan suppliers are commonly written under the client's own law or a neutral forum, with arbitration named for disputes. That is a choice you make, not a consequence of where the supplier sits, and it is worth making deliberately rather than accepting a default template. Suppliers normally invoice in a major currency and receive payment by international bank transfer into a Sri Lankan account. Agree which currency, which route, who absorbs the transfer fees and what the payment terms are before the first invoice. On data, Sri Lanka has a Personal Data Protection Act; confirm its current status and, more importantly, keep your own obligations under British or European law satisfied through the contract, since those are the rules that will be enforced against you. - Governing law, forum and arbitration named explicitly - Currency, payment route, fee responsibility and payment terms - Intellectual property assigned to the client on payment, in writing - A data processing agreement with transfer terms attached where required - Confidentiality covering client data, commercial terms and unpublished work - Named-account access with an offboarding checklist ## What to arrange in the first week The arrangements below take an hour each and prevent most of the friction that remote engagements accumulate over months. - The overlap window, written down, with the standing call inside it - One accountable lead on each side and an escalation route - A shared calendar carrying both countries' holidays - An end-of-day written handover, if the overlap is under three hours - Repository, cloud and secret ownership in your accounts - An answer to what happens if power or connectivity fails, which is a question worth asking any remote team anywhere ## A decision rule Apply these in order and stop at the first that matches. - Rule 1: if your working day is British, European, African or Gulf, a Sri Lankan team fits your clock without anyone working unusual hours. - Rule 2: if your working day is Australian or Singaporean, the overlap is real but sits in the Colombo afternoon; schedule accordingly. - Rule 3: if your working day is North American and you need live daytime collaboration, choose a nearer time zone instead of asking anyone to invert their day. - Rule 4: if your working day is North American and the work can be asynchronous, insist on written handovers and acceptance conditions before you start, not after the first misunderstanding. - Rule 5: if your project has hard release dates, map them against the Sri Lankan holiday calendar before you commit to them publicly. - Rule 6: whatever your time zone, judge the individual team on a written response to an ambiguous requirement rather than on any country-level claim, including the ones in this guide. ## Questions ### What time zone is Sri Lanka in? UTC+5:30, all year. Sri Lanka does not observe daylight saving, so the difference to your own clock changes only when yours does. It is the same offset as India. ### How many hours does a Sri Lankan team overlap with the United Kingdom? A Colombo working day of 09:00 to 18:00 shares roughly three and a half hours with a London working day in winter and about four and a half during British Summer Time. That is enough for a daily call and same-day answers if meetings are kept inside the window. ### Is English used in Sri Lankan software teams? Yes. English is the normal working language of the industry for documentation, code, tickets and client meetings, alongside Sinhala and Tamil in daily life. Verify it with the engineers on your own project rather than relying on a country-level statement. ### What public holidays affect a Sri Lankan development team? The calendar includes a Poya day each month on the full moon, plus national and religious holidays across several traditions, and many dates move year to year. Ask for the supplier's calendar at kickoff and plan releases around it. ### Can a Sri Lankan team work with United States clients? Yes, asynchronously. There is no overlap with a United States working day, so it depends on written handovers, clear acceptance conditions and autonomy rather than on live collaboration. Permanently inverting the team's day is not a stable arrangement. ## Related - [Read about Code Sage Labs](https://codesagelabs.com/about) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/working-with-a-sri-lankan-development-team](https://codesagelabs.com/resources/working-with-a-sri-lankan-development-team) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Building an AI Chatbot That Answers From Your Company Documents" description: "What it takes to build an assistant that answers from your own documents: the options compared, where accuracy comes from, permissions, running cost drivers and when not to build one." url: "https://codesagelabs.com/resources/company-document-chatbot" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Building an AI Chatbot That Answers From Your Company Documents By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. An assistant that answers questions from your own policies, manuals and contracts is now a week of work to demonstrate and a long way from that to a system people trust. The demo is easy because curated questions hit curated documents. Production is harder because real documents are stale, contradictory, permission-controlled and full of tables, and because a confident wrong answer is worse than no answer. This guide covers the decisions before the build. ## Key takeaways - Decide what the assistant replaces before choosing how to build it. - Retrieval quality, not model choice, decides whether answers are correct. - Permissions must be applied during retrieval, never filtered afterwards. - Document ownership and freshness are the ongoing cost, not the model bill. - If your documents contradict each other, fix that first; no assistant resolves it. ## Terms used in this guide These terms appear in every vendor conversation and are worth pinning down before the first demo. - Retrieval-augmented generation (RAG) — fetching relevant passages from your documents and giving them to a language model as the basis for its answer. - Chunk — a passage a document is split into for retrieval; chunk boundaries decide what evidence can be found. - Embedding — a numeric representation of text that lets similar meanings be matched without identical wording. - Vector search — finding passages by meaning rather than keyword; usually combined with keyword search for names and codes. - Reranking — a second pass that reorders retrieved passages by relevance before the model sees them. - Grounding — requiring the answer to follow from retrieved evidence rather than from the model's own training. - Hallucination — a fluent statement with no support in the sources, which is the failure mode users notice last. - Evaluation set — a versioned list of real questions with their expected evidence, used to measure changes. - Deflection — the share of questions answered without reaching a person, the usual business metric for a support assistant. ## Decide what the assistant is for Three jobs are usually bundled into one request, and they have different accuracy requirements, different users and different measures of success. Separating them before the build decides most of what follows. Deflecting repeated internal questions, such as policy and procedure queries from staff, tolerates occasional uncertainty because the person asking can escalate cheaply. Answering customers in your name does not. Drafting, where the assistant produces a first version a person edits and signs off, is the most forgiving of the three and frequently the most valuable, because the human review step is built in. - Internal question answering — moderate accuracy requirement, cheap escalation, measure by deflection and time saved - Customer-facing answering — high accuracy requirement, reputational exposure, measure by escalation rate and complaint rate - Drafting with human review — moderate accuracy requirement, measure by edit distance and time to approved output - Search and discovery — the answer is a document, not a sentence; often the simplest and most useful option ## The build options side by side Three routes cover most situations. Each line gives setup effort, control, permission handling, cost shape, who maintains it and where it fits. - The assistant already in your document suite — setup: days; control over retrieval: none; permissions: inherited from the suite, which is a real advantage; cost: per seat; maintained by the vendor; fits low-risk internal questions over documents already in that suite. - A hosted RAG platform — setup: weeks; control: configuration but not internals; permissions: as good as its connector for your systems; cost: per seat or per query plus storage; maintained by the vendor with your configuration; fits standard documents and standard sources when data residency is acceptable. - A custom build — setup: months to production; control: complete, including chunking, retrieval, reranking and refusal behaviour; permissions: whatever your own systems enforce; cost: build effort plus model and infrastructure usage; maintained by you or your supplier; fits unusual documents, strict residency, deep integration or customer-facing use. - A deliberate non-answer — rewrite and consolidate the documents, add a good search index, and reassess; setup: weeks; cost: staff time; fits any situation where the source documents contradict each other. ## Where accuracy actually comes from Teams reach for a larger model when answers are wrong. That is rarely the cause. If the passage containing the answer was not retrieved, no model recovers it, and the better the model the more plausibly it fills the gap. Measure retrieval first and separately: take fifty real questions, record which passage should answer each, and check whether retrieval finds it. After retrieval, the next largest factor is the source documents themselves. Two policies that disagree, a manual three versions out of date, a table flattened into unreadable text at ingestion: each produces confident wrong answers that look like a model problem and are not. Our production RAG checklist guide covers the operational side of this in more detail, including evaluation, citations and monitoring. - Build the evaluation set before the assistant, from questions people actually ask - Measure whether the correct passage is retrieved, separately from whether the answer reads well - Preserve headings, tables and lists at ingestion instead of splitting on character counts - Record document version, owner and date so staleness is visible - Require citations that open the document at the supporting passage - Make refusal a normal outcome, with a route to a person ## Permissions and data, decided early If your documents have access controls, the assistant must apply them during retrieval so restricted passages never enter the model's context. Filtering the answer afterwards is too late, and an assistant that can summarise a document a user may not open is a data breach with a friendly interface. Settle the data questions before the build rather than during procurement review: which provider processes the text, in which region, whether it is retained, whether it may be used for training, and what is logged. These answers also determine which of the three build options is open to you. - Permissions resolved per user at query time, not per index - Provider, region and retention written down for each model call - Training on your data explicitly disabled in the contract - Logging that records source identifiers rather than full content where possible - Treat retrieved document text as untrusted input, since instructions can be hidden inside it ## What it costs to run The model bill is usually the smallest line and the one everyone asks about first. The durable costs are the document work and the operational attention, and a project that budgets for the build but not for these produces an assistant that is accurate in month one and quietly wrong by month six. - Per-question model and retrieval usage, which scales with traffic and with how much context you send - Storage and reindexing as documents change - A named owner for each document collection, responsible for freshness - Periodic evaluation runs when prompts, models or documents change - Monitoring for ingestion failures, empty retrieval and user-reported bad answers - The review time of whoever handles escalations ## A decision rule Apply these in order and stop at the first that matches. - Rule 1: if the documents contradict each other or nobody owns them, fix that first; an assistant will repeat the contradiction with more confidence. - Rule 2: if the documents already live in one suite, the questions are internal and low-risk, and the suite has an assistant, use it before building anything. - Rule 3: if the sources are standard, residency is unconstrained and the use is internal, trial a hosted platform against your own evaluation set before committing. - Rule 4: if the assistant will answer customers in your name, require citations, enforce refusal when evidence is missing, and plan a human escalation path from the start. - Rule 5: if residency, permissions or document structure rule the hosted options out, build custom, and budget for evaluation and document ownership as part of it. - Rule 6: if the real need is to find the document rather than to be told the answer, build search; it is cheaper, faster and often what people wanted. ## When not to build one Some requests for a document assistant are better answered another way, and recognising that early saves a project. The signals below are reliable. - The questions are mostly about live data in a system, not text in documents - A wrong answer carries legal or safety consequences and no review step is acceptable - The documents are a small, stable set that a well-written page could cover - Nobody will own document freshness after launch - The volume of questions does not justify the operational attention ## Questions ### How accurate can a document chatbot be? Accuracy is a property of your documents and your retrieval, not of the model alone. With clean, owned, well-structured sources and retrieval measured against a real question set, a narrow assistant can be dependable. With contradictory or stale documents, no model produces trustworthy answers. ### Should we use an off-the-shelf tool or build a custom assistant? Start with the assistant in the suite your documents already live in if the use is internal and low-risk. Move to a hosted platform for standard sources, and build custom when data residency, permission handling, unusual document structure or customer-facing accuracy requirements rule the others out. ### How do document permissions work with an AI assistant? The user's access rights must be applied during retrieval so restricted passages never reach the model. Removing content from the answer afterwards does not work, because the model has already read it and can paraphrase it. ### What does it cost to run a document assistant? The model usage is usually the smallest part. The ongoing costs are document ownership and freshness, reindexing, periodic evaluation runs, monitoring and the review time for escalated questions. Budget for those or the assistant degrades quietly. ## Related - [Explore AI development and integration](https://codesagelabs.com/services/ai-development) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/company-document-chatbot](https://codesagelabs.com/resources/company-document-chatbot) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Taking Over a Codebase From Another Agency" description: "How to move software from one development team to another: what to secure before giving notice, how to grade the codebase you inherit, and how to run the first weeks." url: "https://codesagelabs.com/resources/taking-over-an-existing-codebase" type: "guide" author: "Anjula Paulus" published: "2026-10-16" modified: "2026-10-16" publisher: "Code Sage Labs" --- # Taking Over a Codebase From Another Agency By Anjula Paulus, Founder and software engineer at Code Sage Labs. Published 2026-10-16, last updated 2026-10-16. Changing development teams is ordinary and usually survivable. What makes it expensive is sequence: access and ownership are easiest to arrange while the relationship is still cordial, and hardest once notice has been given. This guide covers what to secure first, how to tell a recoverable codebase from a genuinely unrecoverable one, and what a competent incoming team should and should not do in the first month. ## Key takeaways - Confirm ownership and access before you give notice, not after. - Grade the codebase on build, tests, deployment and secrets before planning anything. - Most inherited systems are recoverable; the usual blocker is undocumented operations. - A new team that starts with a refactor is managing its own discomfort, not your risk. - Budget a stabilisation period before the first feature; skipping it costs more later. ## Terms used in this guide The handover conversation uses these words constantly and rarely defines them. - Takeover — a new team assuming responsibility for software someone else built. - Handover — the transfer itself: code, access, knowledge and operational responsibility. - Stabilisation — the first phase after a takeover, spent making the system buildable, deployable and observable rather than adding features. - Tribal knowledge — what the outgoing team knows and has never written down; the most commonly lost asset. - Bus factor — how many people can leave before nobody understands the system. - Runbook — written instructions for operating the system, including what to do when it breaks. - Dead code — code that still exists but no longer runs; dangerous mainly because nobody is certain which it is. - Build reproducibility — whether a new engineer can produce a running system from the repository alone. ## Before you give notice Access tends to end with the relationship, sometimes abruptly and sometimes through simple inattention once the supplier has no commercial reason to help. Everything in the list below is normal to request at any point in a healthy engagement, and much harder to obtain afterwards. Doing it early is not an act of bad faith; it is the same diligence you would apply to any single point of failure. If your contract already puts repositories, cloud accounts and domains in your own name, most of this is already done and the takeover is an administrative exercise. If it does not, that is the first thing to correct, ideally as a normal contractual tidy-up rather than as an opening move in a separation. - Administrative ownership of repositories, with full history - Root or owner access to cloud accounts, not a delegated user - Domain registrar and DNS control - App store and developer accounts in the company's name - Third-party service accounts, billing and API credentials - A current database backup you have restored yourself at least once - Analytics, monitoring and error-tracking accounts ## What to collect from the outgoing team Ask for this while there is still an incentive to co-operate, and ideally make a short paid handover window part of the exit rather than an unpaid favour. A supplier being paid for two days of questions answers them; a supplier doing it for nothing answers the first one. - Build and local setup instructions that a new engineer can follow unaided - Deployment steps, including migrations, approvals and rollback - An environment and service inventory with owners and costs - The secrets, and where they are stored - Architecture notes and the reasons behind the decisions that look odd - Known defects, deferred work and unsupported paths - Scheduled jobs, integrations and anything that runs on a timer - A list of the parts only one person understands ## Grade the codebase before planning anything An incoming team should assess the system against concrete signals rather than aesthetic judgement, because a new team's instinctive reaction to unfamiliar code is that it is bad. Each line below gives one signal at three grades: green is fine, amber needs work in the first weeks, red needs work before anything else happens. - Build — green: one documented command produces a running system. Amber: it works with undocumented steps. Red: nobody present can build it. - Tests — green: meaningful coverage of critical paths, passing. Amber: some tests, unreliable. Red: none, or all disabled. - Deployment — green: an automated pipeline anyone authorised can run. Amber: manual but written down. Red: one person's laptop. - Secrets — green: in a managed store, rotatable. Amber: in configuration files under restricted access. Red: in the repository, or unknown. - Infrastructure — green: defined in code. Amber: manual but inventoried. Red: undocumented resources discovered by billing. - Dependencies — green: current and patched. Amber: behind but supported. Red: on an unsupported runtime or framework version. - Data model — green: documented, with migrations in version control. Amber: readable but undocumented. Red: schema changed by hand in production. - History — green: full repository history transferred. Amber: history exists but is partial. Red: a single initial commit of a zip file. - Observability — green: logs, metrics and alerts with an owner. Amber: logs only. Red: you learn about outages from users. - Documentation — green: a runbook someone has followed. Amber: a stale wiki. Red: one person's memory. ## The first four weeks The purpose of the first month is not features. It is to reach the point where a change can be made and released safely, because until then every feature is a gamble and every estimate is a guess. Resist the pressure to show immediate delivery; a visibly stabilised system is a better first month than a feature shipped through a process nobody trusts. - Week one — reproduce the build locally, inventory services and accounts, restore a backup into a test environment - Week one — rotate every credential the outgoing team held - Week two — get a deployment through the pipeline, however small, and document what it took - Week two — add monitoring and alerting if they are missing, so failures are visible before users report them - Week three — write characterisation tests around the business rules nobody can explain - Week three — produce the system map and risk register, with the red items from the grading named - Week four — make one small, real change end to end, and only then estimate anything larger ## What the new team should not do first A new team's early suggestions are strongly biased towards the unfamiliar being wrong. Some of the suggestions below will be right eventually; none of them is right in month one, when nobody yet knows which behaviour is accidental and which is a business rule someone depends on. - A broad refactor before there are tests to prove nothing changed - A framework or language upgrade while the deployment path is still unproven - Deleting code that looks unused without checking whether it runs - Reorganising the repository, which destroys the blame history you will need - Replacing a working third-party service with a preferred alternative - Proposing a rewrite before the system has been operated for a month ## A decision rule Apply these in order after grading the codebase, and stop at the first that matches. - Rule 1: if the build or the deployment path is red, fix those before anything else, including urgent features; without them nothing can be shipped safely anyway. - Rule 2: if secrets are red, rotate everything the outgoing team could access, on day one, regardless of how the relationship ended. - Rule 3: if two or fewer signals are red and the data model is green or amber, continue with the existing system; it is recoverable and a rewrite would discard working business rules. - Rule 4: if the data model is red, deal with that specifically rather than concluding the whole system must be replaced. - Rule 5: if the runtime is unsupported and cannot be upgraded in place, plan an incremental replacement behind a boundary rather than a full rewrite. - Rule 6: only consider a rewrite when the system cannot be built, cannot be deployed and cannot be understood after a month of genuine effort, and then preserve the business rules before writing any new code. ## Questions ### What should I get before changing development agencies? Administrative ownership of repositories with full history, owner access to cloud accounts, domain and DNS control, app store and third-party accounts, the secrets, a database backup you have restored yourself, and the deployment instructions. Arrange these before giving notice, because access often ends with the relationship. ### How long does it take a new team to take over a codebase? It depends on the state of the build, deployment, tests and documentation rather than on the size of the code. Grade those first. A well-documented system can be operated within weeks; one where nobody can build or deploy it needs that fixed before any other estimate means anything. ### Should a new team rewrite inherited software? Almost never as a first act. A new team's instinct is that unfamiliar code is bad, and a rewrite discards business rules nobody has written down. Rewrite only after the system has been operated for a month and the specific blocker is understood. ### The previous agency will not hand anything over. What now? Work from what you control: the running system, the domain and cloud accounts if they are yours, and any backups. Rebuild the deployment path from the running environment, rotate every credential, and treat the recovery as the stabilisation phase. Then correct the ownership terms so the next transition is administrative. ## Related - [See how we take over existing software](https://codesagelabs.com/services/software-modernisation) - [All guides](https://codesagelabs.com/resources) *Source: [https://codesagelabs.com/resources/taking-over-an-existing-codebase](https://codesagelabs.com/resources/taking-over-an-existing-codebase) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- # Work --- title: "Pyramid Oil & Logistics case study" description: "Website for a heavy transport and logistics company that has operated across Sri Lanka since 1983." url: "https://codesagelabs.com/portfolio/pyramid-oil-and-logistics" type: "case study" client: "Pyramid Oil & Logistics" industry: "Logistics" live_site: "https://www.pyramidlogistics.lk" --- # Pyramid Oil & Logistics A website for a heavy transport business. - Industry: Logistics - Project type: Corporate website - Live site: [pyramidlogistics.lk](https://www.pyramidlogistics.lk) ## The problem Pyramid Oil & Logistics has moved oversized cargo and heavy machinery across Sri Lanka since 1983. Alongside transport it runs vehicle recovery, equipment rentals, weighing, container handling and warehousing. That range of services needed to be presented clearly to customers looking for a heavy-transport partner, with a straightforward way to request a quote. ## What we built A fast, statically generated website with a page for each service line, a fleet section organised by category and specification, a projects showcase, and a quote request flow. The site is built with Next.js and Tailwind CSS, so pages load quickly on mobile connections and content can be updated without touching the design. ## Technologies - Next.js - React - Tailwind CSS ## Outcome The site is live and in use by the company today. ## Related - [All work](https://codesagelabs.com/portfolio) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/portfolio/pyramid-oil-and-logistics](https://codesagelabs.com/portfolio/pyramid-oil-and-logistics) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com* --- title: "Cargo Logistics International case study" description: "Website for a freight forwarding and customs brokerage firm operating out of Sri Lanka's major ports since 2004." url: "https://codesagelabs.com/portfolio/cargo-logistics-international" type: "case study" client: "Cargo Logistics International" industry: "Logistics" live_site: "https://cargologisticslk.com" --- # Cargo Logistics International A website for a freight forwarding business. - Industry: Logistics - Project type: Corporate website - Live site: [cargologisticslk.com](https://cargologisticslk.com) ## The problem Cargo Logistics International handles ocean and air freight, customs brokerage, bonded warehousing and project cargo through Sri Lanka's major ports. The company needed a website that explained those services to shippers, presented the business credibly to international partners, and made it easy to get a quote. ## What we built A website with dedicated pages for each freight service, a freight solutions overview, a company profile and contact and quote flows. Built with Next.js and TypeScript, with a design that keeps the calls to action visible on every page. ## Technologies - Next.js - React - TypeScript ## Outcome The site is live and in use by the company today. ## Related - [All work](https://codesagelabs.com/portfolio) - [Start a project](https://codesagelabs.com/contact) *Source: [https://codesagelabs.com/portfolio/cargo-logistics-international](https://codesagelabs.com/portfolio/cargo-logistics-international) — Code Sage Labs, Colombo, Sri Lanka. Contact: hello@codesagelabs.com*