Sector and scale band
We state the sector and the approximate scale band (branches, users, items, projects), because the solution differs fundamentally between a ten-user operation and a three-hundred-user one.
Always publishedCase studies
We publish the case not the client’s name
We show no client logos, no attribution figures and no testimonials written for us: we show the delivery patterns we work in — the sector and scale band, the situation that reaches us, what we actually implement, what becomes possible afterwards, and what each case does not claim. Whoever needs proof beyond that asks for a direct reference under NDA, which we consider the real evidence rather than the logos.
- No client names, no logos
- No attribution figures that were never measured
- Every case states what it does not claim
- Sector, scale band and scope published
- References on request under NDA
Before the patterns
How to read this page
Before the patterns, here is what this page does and does not give you — because a case study without this disclosure becomes an implicit promise.
The situation and what we implemented
How the process was run before (spreadsheets, email, paper) and what was actually implemented in systems, consoles and integrations — without varnish.
Always publishedWhat each case does not claim
Every pattern ends with an explicit line: what we did not measure, what cannot be attributed to us, and what depends on factors outside the delivery. A line we do not remove when editing.
A mandatory lineWhat we do not publish
Client names and logos, their data and screenshots of their systems, attribution figures, and testimonials. Whoever needs evidence asks for it directly rather than reading it here.
Stated plainlyThe reason for this disclosure is simple: a case-studies page is usually built from logos, figures and testimonials, all of which can be fabricated or bought. So we chose to publish what can be inspected and to provide the real reference on request rather than persuade you with a page.
Cases
Delivery patterns
Eight patterns that recur in our scope of work, each with its sector, scope, the situation we receive, what we implement, what becomes possible — and what it does not claim.
Manual stock counts and differences with no known cause
- The situation
- Stock was managed on spreadsheets and differences surfaced late at period close, with no way to tell whether a difference was a data-entry error, a loss or an unrecorded sale.
- What we implemented
- Consolidating stock into one system with units and storage locations, a periodic count with proper system documents, linking sales, purchase and transfer orders across branches, and a reporting console for differences by cause.
- What became possible
- A difference now appears the same day linked to its document, counting became a system comparison rather than manual matching, and purchasing plans rest on a trusted balance rather than an estimate.
- Odoo · Inventory
- Purchasing
- Custom reporting
Project profitability only visible after the project ends
- The situation
- Project costs were spread across spreadsheets, purchases and supplier invoices, so a project’s margin was known only after closing — when nothing could still be corrected.
- What we implemented
- Running each project as a cost centre, linking purchase orders, stock and progress claims to it, analytical accounting comparing plan against actual, and a margin report per project.
- What became possible
- Each project’s margin became readable while it ran rather than after, variances surfaced in the month they occurred, and a claim could be tied to what was actually executed.
- Odoo · Projects
- Analytical accounting
- Progress claims
Twelve branches and twelve versions of performance
- The situation
- Each branch read its own performance its own way, reports were collected by hand at week’s end, and transfer and pricing decisions rested on stale numbers.
- What we implemented
- Unifying the tills on one stock, agreeing one definition of revenue, margin and returns, and daily reporting by branch, rep and item with reconciliation against accounting.
- What became possible
- The day’s report is ready the next morning, branch comparison uses one definition, and stock transfers became a decision on a figure rather than on an impression.
- Odoo · Point of sale
- Sales analytics
- Accounting reconciliation
Planning by experience rather than by available capacity
- The situation
- The production schedule rested on the planner’s judgement, bottlenecks appeared during execution, and delivery dates were promised that did not hold.
- What we implemented
- Building bills of material, routings and resource times, running requirement and capacity planning, linking it to sales and purchase orders, and reporting resource load.
- What became possible
- The schedule is built on declared capacity, a bottleneck appears a week before it hits, and a delivery date is promised on an achievable basis.
- Odoo · Manufacturing
- Planning and capacity
- Quality
Paper work orders and reports that arrive late
- The situation
- Work orders were dispatched on paper, reports and photos arrived at week’s end, and invoicing was delayed for lack of proof of completion.
- What we implemented
- A field app that works offline and syncs later, with task assignment, signature, photo and location capture, and completion linked to invoicing and work orders in the system.
- What became possible
- Completion is evidenced when it happens, invoices are issued against documented work, and dispatch is based on the technician’s location rather than a supervisor’s estimate.
- Field app
- Odoo · Work orders
- Invoicing
A huge catalogue where reps sell what they remember
- The situation
- Finding an item required knowing its exact code or wording, so teams sold only what they memorised, and slow-moving items accumulated unnoticed.
- What we implemented
- Cleaning the catalogue and unifying categories, alternative codes and units, building search by description and synonyms, and a rep app that works offline and shows stock and price.
- What became possible
- A rep finds the item by description rather than memory, the whole catalogue reaches the field, and slow-moving items appear in a report rather than by chance.
- Odoo · Inventory
- Rep mobile app
- Data cleanup
A statutory requirement run on spreadsheets and exports
- The situation
- Invoices were exported and re-entered manually into an external portal, with risk of error, duplication and late filing, and no log of what had been sent.
- What we implemented
- Connecting invoice issuance to the statutory integration, setting the required fields and codes, logging every submission and response, and exception reports for anything failed or rejected.
- What became possible
- An invoice is submitted when issued with no second entry, every operation leaves a trace in the log, and failures are visible and handled the same day.
- Odoo · Accounting
- E-invoicing integration
- Exception reporting
Each company on its own system, the group without one picture
- The situation
- Each company ran on separate files, the group picture was assembled by hand, and there were neither unified permissions nor documented audit trails.
- What we implemented
- Running several companies in one database with separated data and inter-company accounting, role-based permissions, a change log, and unified and comparative reporting.
- What became possible
- The group picture is read from the system rather than from files, permissions are granted by role rather than exception, and every change leaves a documented trace.
- Odoo · Multi-company
- Permissions
- Unified reporting
Disclosure
What we publish and what we withhold
Two explicit lists, so that the absence of something from this page is never an ambiguous signal.
We publish
- The sector and the approximate scale band
- How the process was run before delivery
- The systems, modules and integrations implemented
- What became possible in management, reporting and connection
- A “what it does not claim” line on every pattern
We withhold
- Client names and logos
- Their data and screenshots of their systems
- Attribution figures and saving percentages
- Written testimonials and satisfaction quotes
- Awards, rankings and certifications
Verification
How our claims can be verified
Four alternatives to logos, the strongest first — because hearing it from a similar client in your sector cannot be imitated.
A direct reference from your sector
We ask a similar client’s approval and arrange a call or visit, subject to an NDA and without disclosing sensitive commercial detail.
The strongest proofA live walkthrough on anonymised data
We show the system or console on anonymised data, so you see the screens, flows and reports rather than composed images.
No client dataA paid small pilot scope
You start with a limited scope and a published output, judging the way we work and the quality before any wider commitment.
A decision without large riskDocuments with no client data
Scope, architecture diagrams and test results from our projects, with commercial data removed.
InspectableFAQ
Questions about this page
Direct answers on why names and figures are absent and what we offer instead.
Why do you not name clients in the case studies?
For two reasons, neither of them marketing: first, our clients’ data is not ours to publish; second, our experience is that a logo on a page proves nothing — a logo can be bought or borrowed, whereas being able to speak to a similar client in your sector under an NDA is evidence that cannot be imitated. So we publish patterns without names and provide references on request. If what you want is logos, we will be direct: we do not put them on public display.
What does “delivery patterns” mean, and why no figures?
A pattern means: the sector, the approximate scale band, the situation that reaches us, what we implement and what becomes possible — with no attribution figure, because a figure without a baseline measured before the project is meaningless. Publishing “a 40% reduction” would be fabrication: no baseline was measured in those cases, and even if it had been, the result is shaped by the market, management and timing rather than by code alone. Instead we present what can be inspected: what was built, what is managed from the console, and how the process was run before it.
How can I verify what you say?
Through four published routes: a direct reference — we arrange a call or a visit with a similar client in your sector, subject to their approval and an NDA; a live walkthrough of a system or console using anonymised rather than real data; a paid small pilot scope where you judge the result before any larger commitment; and documents: scope, architecture diagrams and test results from our projects with no client data. We consider the first the strongest form of proof, which is why we offer it instead of asking you to believe a page.
Are these real projects that were actually delivered?
To be precise: these are delivery patterns that recur in our scope of work, not a display of one particular client engagement. Each pattern describes a scope we genuinely work in, an expected path, what becomes possible and what it does not claim. We named no client, attributed no figure and published no testimonial, because none of those can be evidenced in public. If your decision needs a specific documented case, ask for a similar reference and we will work on arranging it with the client’s approval — which is more honest than a marketing phrasing.
Can I visit a reference site?
Yes, with the client’s approval, because a visit exposes operational detail that belongs to them and is not opened without their consent. We usually arrange a call first with someone in a role similar to yours, then a visit if both sides want one. If no visit is currently available in your sector we say so plainly and offer instead a live walkthrough on anonymised data or a session with the delivery team that worked on a similar scope.
Do you work with clients who ask not to be named?
Yes, and it is common in regulated, financial and competitive sectors. Confidentiality is written into the contract from the start rather than negotiated later. So do not judge our client base from this page: the absence of a name does not mean the absence of work, and the presence of a name does not mean the presence of a result.
Do you publish client testimonials?
We do not. A written testimonial is selected and edited, and is usually requested at the end of a project when satisfaction peaks, so it does not reflect the whole working experience including its difficulties. Instead we offer you a direct conversation with a client, where you hear what was not written — including what they did not like.
Want evidence rather than logos?
Tell us your sector, your scale band and the challenge you face, and we will point to the closest pattern and arrange a similar reference where possible.
- A reference from your sector where possible
- A live walkthrough on anonymised data, not images
- A “what it does not claim” line on every pattern
This page presents delivery patterns, not client engagements by name: we published no client name or logo, no client data, no attribution figure, no testimonial, and no award or certification. Any final outcome depends on factors outside the technical delivery — management, marketing, market and timing — and is not attributable to us alone. A direct reference is arranged with the client’s approval and an NDA, and may not be available in every sector or at every time.