Botlane Custom
When the packaged system isn't enough.
Modifications, integrations, custom workflows, or a system built from scratch — specified in writing, quoted against that specification, and delivered as code you own.
What kind of engagement this is
Scoped project work with a written specification and a fixed quote. It can extend a Botlane system or stand alone.
Scope
Four kinds of work
Most requests are one of these. The first three build on a packaged system; the fourth starts from nothing.
Modify a system
Change how a packaged system behaves for your business — different qualification logic, a different pipeline shape, a different approval path.
Build an integration
Connect a system to something the catalogue does not cover: your ERP, your telephony, an internal API nobody outside your company has heard of.
Custom workflows
Encode the process your business actually runs, instead of reshaping the business around a generic one.
A bespoke system
When nothing off the shelf fits, Botlane builds one — and it passes the same twelve release gates as anything in the catalogue before it is called production ready.
Process
How a custom engagement runs
Specification first. A quote written against a conversation is a guess with an invoice attached.
- 01
Discovery
What the business actually needs, which is not always the feature that was asked for. This is where most of the money is saved.
- 02
Written specification
Behaviour, acceptance criteria, and what is explicitly out of scope — agreed before any code is written.
- 03
Fixed quote
Priced against the specification. A change to the spec produces a revised quote in writing before work continues, rather than a surprise at the end.
- 04
Build
With review checkpoints where you see working software, not a status update describing software.
- 05
Acceptance
Tested against the criteria in the specification, by you. The criteria were agreed at the start precisely so this step is not a negotiation.
- 06
Handover
Source, tests, documentation, a deployment path into your existing system, and a note on what this does to future upgrades.
Included
What you get
- Source code in your repository, under your ownership
- The written specification the work was accepted against
- Automated tests covering the behaviour that was built
- Documentation for operating and changing it
- A deployment path into your existing system, not a second thing to run
- An upgrade compatibility note: what this costs you at the next upstream release
From you
What we need from you
- A decision-maker who can settle scope questions without convening a committee
- Access to the system or environment the work targets
- Acceptance criteria you are willing to be held to as firmly as we are
- Real examples of the data and the edge cases, not the tidy version
Boundaries
Who does what.
Stated plainly so nobody discovers the line during an incident.
| Stage | Yours | Botlane’s |
|---|---|---|
| Specification | Deciding what the business needs, and signing off the spec. | Turning that into acceptance criteria and explicit exclusions. |
| Build | Availability at review checkpoints, and answers to scope questions. | Implementation, tests, documentation. |
| After acceptance | Owning the code, and carrying it through upgrades unless Managed covers it. | The handover and the upgrade compatibility note. |
Not included
What this is not.
Custom work extends a system. Two things sit outside it, and both cost money elsewhere rather than being folded silently into a quote.
Honestly
Before you ask for custom work
Customization keeps costing after the invoice is paid. These are the things we would say in the first call, so here they are before it.
Every modification to a Distribution adds upgrade burden. When the upstream project moves, your changes have to move with it — and that cost recurs at every upgrade, not once.
Configuration is cheaper than code. If a packaged system can be configured into the shape you need, we will tell you that rather than quote a build.
A workflow that exists because of one person's habit is usually worth changing rather than encoding. We will say so once, and then build what you decide.
If what you are asking for would help every customer, it may belong in the packaged system instead — where Botlane maintains it and you do not pay to carry it alone.
A bespoke system is the most expensive option on this site. It is the right answer sometimes, and the wrong one more often than people expect.
Cost
How this is priced.
Quoted fixed against the written specification rather than billed by the hour — you should not be paying for our estimating error. A change to the spec produces a revised quote in writing before work continues. No day rate is published, because the specification determines the price, not the calendar.
Ask for a scoped quoteQuestions
Common questions about Botlane Custom.
Do we own the code?
Yes. Custom work is delivered into your repository under your ownership. Where it modifies a Botlane Distribution, the upstream project's licence still governs the upstream code — we do not relicense work we did not write.
What happens to our modifications when the system upgrades?
They have to be carried forward. At handover you get a written note on which parts are likely to conflict with future upstream changes and how expensive that is likely to be. Under Botlane Managed we carry them across upgrades; otherwise your team does. Either way, nobody should be surprised by it at the next release.
Can you work on a system we did not get from Botlane?
Sometimes, depending on what it is and how it is built. We will say no if taking it on would mean guessing, rather than quoting for a discovery phase that ends in a shrug.
How small can a piece of work be?
Small enough that writing a specification is still worth it. Below that line it is usually configuration, and we will point you at the setting instead of quoting for a build.
Want us to carry it through upgrades?
Under Managed, custom work is maintained across releases rather than becoming your team's problem at the next upstream version.