Custom systems
Not every process should become a system.
Before building anything, Redbeard finds out whether it is worth building. If it is, you hire it in stages: each stage produces something on its own, and each stage has a way out.
Fit
What makes a process fit, and what does not
You can check the list below on your own, today, without talking to anyone. If what describes your case sits under "does not fit when", the honest answer is that software is not your problem right now, and saying so is cheaper for both of us than finding out after three months of building.
Fits when
- The work repeats and follows a rule, even if nobody has ever written that rule down.
- Requests come in through several channels: chat, e-mail, phone, and none of them is the official one.
- More than one person touches the same case, and knowing where it stands means asking someone.
- Mistakes cost money or trust: rework, missed deadlines, a customer billed twice for the same thing.
- The information lives in spreadsheets, conversations and people's heads, and closing the month is a reconstruction.
Does not fit when
- The process changes every week. A system freezes decisions, and freezing something that is still taking shape is expensive and gets in the way.
- The volume does not justify it. Three cases a month in a shared spreadsheet is the right answer, and it will keep being the right answer.
- The answer is an internal agreement, not software. When two teams disagree about who decides, no system settles it. It only records the disagreement faster.
- An off the shelf tool already solves it as it is, without bending your operation around it. In that case we tell you which one, and we do not build.
How it works
What you have in hand, at each moment
- First, a clear scope: what is going to be built, written in enough detail to become a contract, before a build price exists.
- Then, the system in use: live, with the rules of your operation inside it, and the code in your company's repository.
- And then, someone watching afterwards: operation carries on, and every month it hands back the record of what was checked, found and fixed.
Contracting
Three commitments, not one
The risk of hiring a custom system is almost never technical. It is committing to a full amount before knowing exactly what will be built. That is why the contract is split, and you can stop after any stage and keep what it produced.
Process discovery
Hired on its own, priced on its own. This is where the process is mapped as it actually happens: where requests come in, who picks them up, where they stall, what has already been tried. It ends in a document describing the current process, the bottlenecks by name, and what each one costs in rework and delay.
The way out: the document is yours, and it still works if the build happens with another company, or with nobody.
Fixed scope
What will be built, written in enough detail to become a contract: screens, rules, integrations, what stays out. The price of the build is born here, after discovery, and not before. A price estimated without discovery is a guess wearing the clothes of a proposal, and it is where most projects that double in size begin.
The way out: the scope is yours, and any other supplier can quote against it.
Build and operation
The system is built against the approved scope, with an automated test for every rule that must not break unnoticed, and delivered with its documentation in your company's repository. Operation continues after delivery, on a monthly plan, and is contracted separately.
The way out: the code and the documentation are yours from day one, not from delivery.
Change
What happens when the scope changes halfway
It changes. It always changes, and anyone promising it will not is selling, not building. What prevents the friction is not blocking the change, it is having agreed beforehand what to do with it.
- Every change requested becomes an item with a declared effect on schedule and price, before a single line is written.
- You decide between taking it now, with the effect it carries, or taking it later, in a following stage. Both are legitimate answers.
- When a change reveals that the scope was wrong, and not merely incomplete, the conversation is about rewriting the scope, not stacking items onto it. That gets said at the time, even when it is uncomfortable.
- Nothing enters through a conversation. A change agreed on a call is a change nobody remembers the same way two months later.
Ownership
What is yours, in writing
Technical lock in is rarely a clause. It is usually a consequence: code that exists only on the supplier's server, with no documentation and an unreadable history. The contract here inverts that, item by item.
- The code lives in your company's repository, under your company's account, from the first day of the build.
- The documentation travels with the code, in the same repository, and describes the decisions, not just the installation.
- The data is yours, exportable in an open format, without asking permission and without depending on us to get it.
- What is confidential stays confidential: your project never becomes portfolio material, and no screen of yours appears on this site.
Technical risk
How the system is kept from failing silently
The failure that costs money is not the one that takes the system down, because that one shows up immediately. It is the one that keeps running and returns the wrong number for three months. The four answers below exist against that kind.
- Every rule that cannot fail in silence is checked on its own, on every change. Experience decides which rules those are, and that is the part no tooling decides.
- Every change to data keeps the previous value, the new one, the author and the time. Without a trail, "it was right last week" is an argument with no referee.
- Access by role, HTTPS enforced, protected sessions, and access logs kept. Security is configuration that gets checked, not a promise.
- Monitoring that tells Redbeard before the problem reaches you, with a monthly verification routine and a report of what was found and fixed.
The first step
What process discovery delivers
Not a score, not a certificate, not a report full of generic recommendations. It is your own process handed back in readable form, with the bottlenecks named in your words and what each one costs. Below, the shape of the document.
- How the work happens today
- An order closed in one tool is typed again, by hand, into anotherSales closes it in the CRM. Delivery starts from a spreadsheet rebuilt every morning
- Bottleneck 1
- The same order exists twice, and the two copies drift apartMeasured in the interviews: 4 to 6 corrections a month, found by the customer rather than by the team
- Bottleneck 2
- Nobody can say where an order stands without asking someoneCost: 2 to 3 interruptions a day for the one person who knows
- Bottleneck 3
- This is an agreement, not a systemSales and delivery disagree on when an order counts as confirmed. Software would record the disagreement faster, it would not settle it
- Recommended next step
- Scope for bottlenecks 1 and 2, in that orderBottleneck 3 leaves the scope by decision, and returns if the agreement gets settled
Example written with fictional data, to show the shape of the document. No client's process discovery is published, not even anonymized: what identifies a company is not its name, it is the shape of its process.
Limits
What Redbeard does not do
Open ended scope, billed by the hour, with no declared end
Hourly billing without a scope moves all the risk to whoever is paying, and removes any incentive for the supplier to finish. The scope is fixed before the build starts.
A deadline before discovery
A deadline given without knowing the process is a guess. When it slips, and it does slip, the conversation turns to blame instead of to the system.
Turning your project into portfolio material
No screen, name, logo or metric belonging to a client appears on this site or anywhere else. The screens published here are illustrations with fictional data, and they say so in the caption.
Promising cover that does not exist
The operation plans include a monthly routine and monitoring, not 24 hour attendance. Publishing a response time the operation does not meet would be easier, and it would be a lie.
Next step
Tell us about the process you want to change.
A description in plain language is enough for a first conversation: where the work comes in, who picks it up, where it usually stalls. If the answer is that it is not the right time, it comes back exactly like that.