How we scope custom software projects
How Birchline Digital scopes custom software, AI, and automation work: what determines custom software cost, why similar-sounding projects are priced differently, and how published investment ranges should be read.
Written by Derick Ribeiro Offei, founder of Birchline Digital — a software engineer focused on custom software, AI systems, business automation, and operational systems.
Birchline prices the system being engineered, not a package, a feature count, or a generic hourly estimate. Scope follows the business problem, the workflows and people involved, the systems and data the software must work with, and how critical it is to the operation. Published investment ranges show the territory; the actual scope is established before anyone makes a material commercial commitment.
What determines custom software cost
Software built around the way your business works has to account for how the business actually works. These are the factors Birchline scopes around:
The business problem and the outcome
What has to change in the operation, and what would count as success. Scope starts from the outcome, not from a feature list.
Workflows and operational paths
How many distinct paths the work actually follows — including the exceptions, handoffs, and edge cases people handle today without thinking about them.
Users, roles, and permissions
Who uses the system and what each role may see or do. One role is a different engineering problem from five roles with approval rights.
Integrations and existing systems
The systems the software must read from, write to, or live alongside, and how well those systems expose their data.
Data requirements, migration, and quality
What data the system needs, where it lives now, and how much reconciliation it needs before it can be trusted.
Automation and AI, where appropriate
Which steps can be automated reliably, and whether AI materially improves any of them. Often it does not, and that is a valid finding.
Security, privacy, and compliance
Access control, audit trails, retention, and any sector obligations — designed in from the start rather than added later.
Interfaces and user experience
The screens, portals, and interactions each role needs, and how much care the experience demands.
Reliability and operational criticality
What happens if the system is unavailable or wrong. A reporting view and a system that moves money justify different rigour.
Deployment and implementation
Hosting, environments, cutover from existing tools, and rollout to the people who will use it.
Testing and acceptance
How behaviour is verified and what your side needs to see before accepting the work.
Ongoing operation and support
What the system needs after launch — monitoring, updates, and continued engineering as the business moves.
Why custom software costs vary between similar-sounding projects
Two businesses may both ask for a "customer portal." One needs sign-in, a dashboard, and a simple database. The other needs multiple user roles, an ERP integration, payments, document workflows, approval logic, historical data migration, and operational reporting.
Both are called customer portals. They are not equivalent engineering engagements. The name describes the surface; the scope is set by everything behind it.
How a project is scoped at Birchline
Intro conversation
A free conversation about the problem, the operation, and what a good outcome looks like.
Credible fit
Whether there is a real fit — for the problem, the timing, and the investment territory.
Systems & AI Discovery, when warranted
When the problem is large, ambiguous, or technically uncertain, a paid Discovery engagement produces the architecture and scope.
Defined engineering scope
The agreed system: behaviour, integrations, data, security, and acceptance.
Proposal and investment
A confirmed investment for that defined scope.
Engineering engagement
Delivery through Birchline's engineering stages.
Not every project needs a separate Discovery engagement. Straightforward work that is already sufficiently defined can move directly to scope and proposal. Systems & AI Discovery starts at $2,500; substantial Discovery typically runs $5,000–$7,500+.
How to read Birchline's published software project pricing
- "Starting at" is the lower boundary for a credible engagement in that capability — not a promised quote.
- "Typical" ranges describe where many appropriately scoped engagements fall — not a fixed package.
- Larger or unusually complex systems can exceed the published typical range.
- Birchline does not reduce the quality of a scope to force a project into an advertised number.
- The aim is an appropriate scope before either side makes a material commercial commitment.
The published figures for every capability are on pricing.
What Birchline does not price by
Birchline does not begin by forcing a project into a predetermined package, and does not add technology to enlarge a scope. Every component has to earn its place in the system.
AI in particular is included only when it materially improves the solution. Rules, integrations, and conventional software are often the better answer — see when AI is the wrong tool. Sometimes the right answer is not custom software at all; that is covered in build vs. buy. Schedule is scoped the same way, from the same factors — see how long custom software takes.
Ready to talk about a specific system? Discuss a project.
Where a decision like this normally gets made
Most of this is decided before anyone writes code. A Systems & AI Discovery engagement from $2,500 maps the operation, tests whether custom software or AI is actually the right answer, and produces the architecture and scope. If it concludes you should configure what you already own, that is a legitimate result. Published engagement sizes are on pricing, the delivery stages on how we work, and the capabilities themselves on capabilities.