ScaleDevelopment in Cambodia.
Bespoke builds when off-the-shelf doesn't fit: source code yours from day one, no lock-in.
- Custom Software Development
Bespoke web and back-office systems when off-the-shelf doesn't fit, on boring, durable tech your engineers can take over.
- Mobile Development
iOS and Android via React Native: driver apps, field-rep apps, manager dashboards and customer apps. Source code yours.
- API Development
REST and GraphQL APIs, documented, versioned and observable from day one, designed for your engineers to inherit.
What does Scale's Development practice cover?
Scale's Development practice designs and builds custom software (mobile applications, APIs, back-office systems, and bespoke web products) for Cambodian operators who need software that fits their business exactly, not a configurable platform that requires the business to fit the software. Source code is yours from day one of go-live, with no per-user fees on what we ship.
Custom development is the right answer when the problem cannot be solved by configuration. When a retail chain's pricelist rules are complex enough that a packaged module would need more custom code than a clean build. When a logistics operator's dispatch algorithm has to model road conditions no off-the-shelf routing engine understands. In both cases the operational core is the product, and the product needs to be owned, not rented.
Source code ownership is a first principle of how we work. Every project ends with a full repository handover to a client-controlled repository on go-live day. We do not retain source code, we do not hold deployment credentials, and we never structure an engagement so that you need to call us to deploy a bug fix.
When should you build custom versus buy off-the-shelf?
Build custom when the operational logic that differentiates your business cannot be represented without destructive workarounds in a configurable platform. Buy off-the-shelf when the business process is standard and the platform's configurability covers your real requirements, not just the requirements you think you have before you use the platform.
The honest answer: most businesses overestimate how unique their requirements are. An accounting system is an accounting system. A CRM is a CRM, and what a CRM build covers is mostly standard. In these domains, the requirements of 80% of Cambodian SMBs are well served by the standard modules our System Solutions builds start from. Beyond those, bespoke is usually argued from familiarity with a legacy system or reluctance to change a process.
Lock-in runs in both directions. Off-the-shelf platforms lock you into their data model, API rate limits, licence terms and roadmap. Custom software locks you into the technology chosen at build time and the quality of the team that built it. The mitigation: standard open-source technology (TypeScript, PostgreSQL, React), source code yours from go-live, a runbook another team can take over, and month-to-month support.
The decision framework we use with clients:
- Is there operational logic a platform cannot represent without bending its data model?
- Is that logic the thing that makes the business competitive?
- Can you own it after handover, and operate it?
- Is it cheaper over three years than licensing and workarounds?
How long do development projects take?
A typical SMB custom development project (a business-logic API and admin dashboard, or a mobile app with a back-end) runs 8–16 weeks from signed contract to production deployment. Complex mid-market products with multiple user roles, offline mobile capability, and multi-entity data models run 16–32 weeks.
What most often pushes an SMB product past 8–16 weeks, or a mid-market product past 16–32 weeks, is scope change: requirements added after the specification is locked. Anything not in the specification is documented, estimated and quoted as a change order before work starts, so the schedule holds and the cost of every addition is visible in advance.
- Discovery (weeks 1–2): requirements workshops, user-story mapping, API contract and data model design, integration scoping. Output: a fixed-scope specification.
- Design (weeks 2–4): wireframes and user flows in Figma, database schema finalised, API routes defined, iOS and Android interaction design.
- Build (weeks 4–14): back-end API (TypeScript, Node, Postgres), front-end (React or React Native), tests alongside code, weekly client demo.
- Test and QA (weeks 12–16): end-to-end run on staging, performance testing, security review (authentication, authorisation, input validation), client UAT.
- Launch (weeks 14–18): production deployment on AWS, DNS cutover, monitoring and alerting configured, performance baseline recorded, hypercare begins.
- Handover (weeks 16–18): repository transferred to you, deployment runbook delivered, infrastructure credentials transferred, CI/CD pipeline documented and handed over.
What stacks do we use and why?
We build on TypeScript, Node.js, PostgreSQL, React, React Native, and AWS, chosen for ecosystem size, hiring access in Southeast Asia, long-term maintainability, and Cambodia-specific operational requirements. Every technology choice is documented in the handover package with its rationale. Source code yours: your engineers inherit it and can read why each decision was made.
- TypeScript and Node: the API layer. Static types catch interface mismatches and wrong response shapes at compile time, not in production; strict TypeScript, same language as the front-end.
- PostgreSQL: the data layer. Correct multi-currency arithmetic (NUMERIC, not FLOAT), JSONB documents beside relational tables, row-level security for multi-tenant systems, identical on a laptop or RDS.
- React and React Native: the screens. React and Next.js for the web; one React Native codebase for iOS and Android, not Expo managed workflow where custom native modules are needed.
- Python: data pipelines and ML-adjacent work. CPU-bound jobs (inference, image processing, heavy data transformation) run as Python microservices beside the Node API, behind a defined contract.
- AWS: the infrastructure. Mature managed services (RDS, ECS, Lambda, S3), defined as code in Terraform or CDK, proprietary services avoided where possible so the codebase stays portable.
What about ownership, IP, and source code?
Source code is yours from the day of go-live, transferred to a client-controlled repository with no strings attached, no licence fees, and no ongoing dependency on Scale to deploy or modify it. Intellectual property created during the engagement is assigned to you in the contract, not licensed to you.
Our position is simple: the software we build for you is yours. Not licensed to you under a recurring fee, not hosted by us with a clause that gives us leverage. The git repository moves to your GitHub, GitLab or Bitbucket organisation on go-live day, deployment credentials move with it, and monitoring runs on your accounts, not ours.
No per-user charge on bespoke logic. If we build a CRM for your sales team, you do not pay per seat. If we build a warehouse app for 20 warehouse staff, there is no per-user charge. Running it costs AWS infrastructure, charged by usage, not by user, plus whatever support you choose.
Generic infrastructure components are shared; business-logic code written for your engagement is yours exclusively. The handover package on go-live day:
- The full source code repository, with commit history.
- A deployment runbook with step-by-step instructions to deploy from scratch, environment variables and secrets management included.
- An infrastructure-as-code repository (Terraform or CDK) for the AWS resources.
- A CI/CD pipeline configuration that runs tests and deploys automatically on merge to main.
- A system architecture document covering data model, API routes, integration points and key design decisions.
Frequently asked questions: Development
Do we need an in-house technical team to hand over the software to?
No. Most clients have none at go-live. The runbook is written so any competent developer can take over, with no Scale-specific knowledge needed. Month-to-month managed support can be cancelled at any time, and the handover package has everything a successor needs.
Can you build mobile apps that work offline in areas with poor connectivity?
Yes. React Native with a local SQLite or Realm database caches data locally and syncs when connectivity returns. The sync logic (conflict resolution, partial sync) is the hard part and is scoped in discovery. Built so far: field surveys, delivery confirmation, agricultural input distribution.
How do you handle Khmer language in mobile and web apps?
We use Noto Sans Khmer or Battambang for body text and Khmer-compatible fonts for headings; React Native renders Khmer correctly on iOS and Android. Line-breaking is tested for Khmer strings, and date and number formatting (KHR with Khmer numerals if required) sit in the i18n layer.
Can you build on top of an existing codebase we already have?
Yes, after a paid code audit of 1–2 weeks: stack and dependency versions, test coverage, security posture, schema quality and deployment infrastructure. The output is a technical debt register and a recommendation: extend as-is, refactor then extend, or rebuild. We do not extend codebases we have not audited.
What happens if we need a feature added after go-live?
As a new scoped engagement, run like the original: discovery sprint, fixed quote, build, test, deploy, so the cost is visible before work starts. Defects in the original scope carry a 90-day warranty at no charge; after that, managed support or a small change order.
Do you build APIs that other developers can integrate against?
Yes. A documented, versioned REST or GraphQL API is a common scope: OpenAPI (Swagger) documentation, versioned routes (v1, v2) with a deprecation policy, JWT or API-key authentication, rate limiting and quotas, a sandbox for integration partners, and an SDK or integration guide for external consumers.
Can you help us with AI or ML features inside a custom application?
Yes, within a defined input/output contract: document classification, invoice data extraction (OCR plus LLM), predictive reorder points, FAQ chatbots over a known knowledge base. No speculative ML research. The AI layer runs as Python (FastAPI) microservices behind an API contract, replaceable on its own; see our AI & Data practice.
What is your policy on open-source libraries and licences in our codebase?
We use open-source libraries extensively and document every licence in the handover package. GPL and AGPL are avoided in commercial codebases, since they can require the whole application to be open-sourced; MIT, Apache 2.0 and BSD are preferred. An ambiguous licence is flagged in discovery for your sign-off.