Technology Services · Custom Software
Custom software development, when a product will not do.
Order processing tools, internal systems, workflow automation and admin dashboards built for how your operation runs, and connected to the systems you already use.
- Built on
- The Service Layer, the DI API and supported SDKs. Nothing writes to the SAP Business One® database directly
- Runs
- Beside SAP Business One rather than instead of it, so the ERP stays the system of record
- Upgrades
- Work built on supported interfaces carries across a SAP Business One upgrade with minor changes
Before any code
Four answers to “the system does not do this”
Only one of them is a development project, and it is the third one. We work down this list in order, and say so out loud when your problem stops before the bottom.
More of it becomes yours to own
- 01
Configure what is already there
No code
- When it is right
- The behaviour exists in SAP Business One and nobody has set it up. Far more common than people expect, particularly around pricing, approvals and document layouts.
- When it is not
- The configuration only approximates the process and everyone agrees to work around the gap. Workarounds become permanent.
- What it costs later
- Nothing. This rung costs you a day of somebody's attention and carries across every upgrade untouched.
- 02
Extend inside the product
User-defined fields, queries, alerts
- When it is right
- The data model is nearly right and needs a few fields, a validation, a query or an alert. Still inside the boundary SAP Business One supports.
- When it is not
- The extension starts holding logic that ought to be a program. Formatted searches that call other formatted searches are a warning sign.
- What it costs later
- Documentation, mostly. These are cheap to build and easy to forget, and an undocumented alert is indistinguishable from a bug.
- 03
Build an application beside it
Custom software
- When it is right
- The process is real, repeated and specific to your business, and no packaged product models it. This is where most of our development work sits.
- When it is not
- It is really a reporting problem, or a training problem, or one person's preference. Software will not fix any of those.
- What it costs later
- A codebase somebody has to own. Worth it when the process is genuinely yours, expensive when it is not.
- 04
Replace the process
Do not build
- When it is right
- The step exists because a previous system could not do something, and that system is gone. The honest answer is to stop doing it.
- When it is not
- The step is a control, an audit requirement or somebody's actual job. Then it is not overhead, it is the work.
- What it costs later
- Nothing to maintain, which is the point. The hard part is agreement, not engineering.
We work down this list, not up it. A development quote for something that turns out to be rung one is the fastest way to lose a client's trust.
Where these projects start
The spreadsheet is doing six jobs at once
Nearly every custom application we build replaces one. Scoping it means naming what the file is quietly responsible for, because each of those is a requirement whether or not anyone writes it down.
- 01
A database
It is the record. The real one, whatever the ERP says.
A schema with types and constraints, so a date cannot be text and a quantity cannot be blank.
- 02
A validation layer
One person knows which combinations are impossible, and catches them by eye.
Rules written down and enforced at entry, in the same words that person would use.
- 03
A workflow engine
A tab colour means it is ready. An email means it is approved.
Explicit states and transitions, with the approval recorded rather than remembered.
- 04
An audit trail
There is not one. A file named final v3 is not an audit trail.
Who changed what, when, and what it was before. Usually the single most valuable thing gained.
- 05
A permissions system
Everyone who has the file has everything in it.
Access per role, so the credit limit is visible to the people whose job includes it.
- 06
A reporting tool
A pivot table that one person can rebuild and nobody else can.
Queries against structured data that anybody can run and nobody can break.
The spreadsheet usually keeps existing afterwards, and that is fine. What changes is that it stops being the record.
Scope
What we build
Six shapes this work takes. Most projects are one of them and grow into a second.
- 01
Internal business systems
The tools your team uses all day that no off-the-shelf product quite covers.
- 02
Order processing and workflow tools
Intake, validation, approval and fulfillment workflows that replace email threads and spreadsheets.
- 03
Admin dashboards and back-office apps
Screens for the people who manage pricing, customers, catalogs and exceptions.
- 04
Workflow automation
Scheduled and event-driven jobs that create documents, send notifications and move data between systems.
- 05
Data tools and imports
Import, cleanse and transform tools for catalogs, price files and partner data.
- 06
Replacing fragile tools
Access databases, macro-heavy spreadsheets and aging in-house apps rebuilt on a supportable stack.
Handover
You should be able to leave
A custom application is a dependency. The only responsible way to sell one is to make sure it does not depend on us.
One exception, stated plainly: backend infrastructure and server credentials remain controlled by TranzDigital unless explicitly agreed otherwise.
- 01
Source code
In your repository, with the commit history intact, not a zip file at the end.
- 02
Documentation
How it is built, how it is deployed, and the decisions that would otherwise have to be reverse-engineered.
- 03
A runbook
What to do when it fails at 6am, written for somebody who did not build it.
- 04
Schema and data
The database structure and an export path, so the records outlive the application.
- 05
Ownership terms
Set in the agreement before development starts, not negotiated afterwards.
What it usually connects to
The rest of the system
- CoreSAP Business OneThe system of record everything else reads from and writes to.Overview
- Layer 01B2B eCommerceCustomers who order themselvesA portal with their pricing, live stock and account history. Orders arrive as SAP Business One sales documents.See it
- Layer 02Sales Rep AppCustomers who need a visitReps carry pricing and stock on the route, work with no signal, and sync orders when they reconnect.See it
- Layer 03Inventory CountingMaking the stock figure trueBarcode counts and cycle counts, with variances reviewed before anything posts to the ledger.See it
- Layer 04Price Label PrintingThe shelf edgeLabels generated from the same item and price data, so what is on the shelf matches the invoice.See it
Questions
About custom development
Next step
Describe the problem. We will tell you what it takes to solve it.
Send a few lines about the process or system you are dealing with. We come back with questions, options and a realistic sense of effort.