Internal tool development: where losses begin
While there are few processes, records live in spreadsheets and messages: requests, stock balances, order statuses, approvals.
Each department keeps its own version of the file, and reconciliation turns into a manual accounting operation — export, matching by SKU, finding discrepancies by eye. By the time the numbers match, they are already outdated.
The cost of this scheme does not show up immediately. Data discrepancies between departments accumulate: the warehouse sees one balance, sales sees another, finance reconciles a third version.
Decisions are made with delay, and the cause is sought in messages rather than in a system where you can see who changed a record and when.
Internal tool development begins where manual reconciliations stop paying off. Internal dashboards are placed on top of existing databases and reference data: one input form, one calculation logic, a change log for each record, roles and field-level permissions.
For a quick start we use Tooljet — on it we assemble working interfaces to accounting data without rewriting the core of the accounting system.
Then internal process automation kicks in: approvals, notifications, statuses, scheduled exports. Reporting is compiled in hours instead of days, and the argument "whose number is correct" is replaced by a link to the record. We explain how this is covered.
What changes after implementation: measurable effect
The report compiles itself instead of being transferred by hand
Previously, an export for management was assembled in a spreadsheet: export from the accounting system, manual reconciliation, merging sheets.
After implementation, the report is built from the same data as the working screens, so preparation time drops from several hours to minutes, and the number of manual transfers between files falls to zero.
This also removes the source of discrepancies itself: the number in the report and the record in the request card are the same row, not two similar ones.
One data source instead of messages
Reference data, statuses, and change history live in one place; every edit has an author and time. Approval no longer depends on who has the latest version of the file open, and finding the current value takes one query instead of a series of clarifications in chat.
A side effect is transparent audit: you can see who changed a field and when, and which report was later calculated from it.
Input errors are caught at entry
Free text is replaced by selection from reference data, required fields are linked, and values are checked at the moment of filling, not during reconciliation.
On typical processes, this yields a multiple reduction in input errors on key fields and removes a whole class of rework: an incorrect status or duplicate request simply cannot be created. The system performs the check, not a person who is tired by the end of the day.
A request does not wait for free hands
Roles and routes are described in the tool: a request immediately goes to the right assignee, the status is visible to all participants, and response time is measured rather than reconstructed after the fact from messages. The freed hours go to substantive work, not coordination and reminders.
Implementation formats: platform, custom code, or hybrid
The choice here is not about fashion, but about four signs: how often screens change, how many external systems need to be connected, how non-standard the logic is, and who will maintain the tool after launch. According to them, the three options diverge clearly enough not to choose at random.
| Option | When it fits | Limitations |
|---|---|---|
| Low-code platform (Tooljet) | 5–10 screens, typical accounting scenarios, roles and action log out of the box; a working tool is needed quickly, edits are made by the team without a dedicated frontend | Non-standard logic and heavy visualization hit the platform's limits; part of the behavior is described inside the vendor |
| Custom code | Unique calculations, field-level permissions, high load, strict data storage requirements; full control over the model and release cycle is needed | Longer to the first version, requires its own support team, each enhancement goes through a full release cycle |
| Hybrid approach | Core, permissions, and integrations on custom code; operational screens, reports, and admin panel on the platform | Stable contracts between the parts and support for two environments are needed |
The criterion is simple: look at what changes most often. If screens and reports change, the platform removes routine work, while the non-standard core remains in your custom code.
If access rules and the logic itself change more often, custom code or a hybrid wins, where the platform is responsible only for presentation.
How implementation proceeds: stages of engineering work
We start implementation from how work happens today: where records are kept, which exports are assembled by hand, at which step data diverges.
Based on the process review, we fix the list of operations to move into the tool, and what we deliberately leave with the previous systems — otherwise the scope of work grows without benefit.
- Process and data review: interviews with executors and the department head, analysis of spreadsheets, exports, and external systems that will need to be exchanged with.
- Data schema and role model: we describe entities and relationships, who reads and who changes records, which checks are mandatory at entry.
- Assembling a working prototype: screens, reports, and integrations on Tooljet — immediately on real data, not stubs.
- Pilot users: one or two teams work in the tool in parallel with the previous method; we compare numbers and correct discrepancies.
- Refinement based on pilot feedback: we clarify forms, permissions, and scenarios that in practice turned out different from the description.
- Handover to operation: access, update regulations, employee training, and a clear procedure for further enhancements.
Each stage closes with an agreed artifact — a data model, prototype, or regulation. Therefore the next step does not begin on guesses, and the pilot result is visible before the tool becomes primary.
What we hand over: configurations and regulations
Project handover is not "account access and a one-hour call," but a set of artifacts by which your team can develop the tool without us.
We collect them during the work, not in the last week: at acceptance, each item can be opened and checked against what actually works in production.
- Working application configuration: description of interfaces, data queries, and relationships between them, exported in a versioned form. It deploys in your environment and reproduces current behavior one-to-one.
- Data schema: tables, relationships, field types, constraints, and migration order. It separately marks where the schema is normalized and where it is deliberately denormalized — for report speed.
- Access rules: roles and groups, what each of them sees, restrictions at the query and individual field level. A list of service accounts indicating which systems they are connected to.
- Integrations: list of external systems, authorization method, failure points, and behavior when the source is unavailable — what is shown to the user instead of data.
- User instructions: short role-based guides — how to create a record, how to approve, how to export a report. Plus an administrator checklist: how to add a user and grant permissions.
- Maintenance regulations: what we do on a planned basis, what on request, response times for different classes of failures, and the procedure for rolling back to a previous version.
- Decision log and known limitations: why this storage method was chosen, which scenarios are deliberately not covered, and in what order it makes sense to enhance them.
Ownership remains with you: the tool can be maintained by your own team, handed to another team, or returned to us. Onboarding a new engineer into the project using such a set takes days, not weeks — they do not need to reconstruct logic from code and messages.
Case study: how manual reconciliation and the request queue disappeared
Before
The client was a department of six operators that reconciled requests between the accounting system and supplier registries. Every morning two files were matched line by line manually, and discrepancies were distributed via emails and spreadsheets.
Continuous reconciliation took 3-4 hours a day, the request queue reached 400 rows by the end of the week, and 4-6% of items went into work with an error: duplicate requests, missed cancellations, quantity discrepancies.
After
We built an internal tool: scheduled data collection, matching by a composite key — request number, item, and shipment date — plus priority rules for source conflicts.
On ToolJet we assembled the operator workstation: filters by discrepancy type, one-click confirmation, edit history for each record. Discrepancies are no longer found by eye — they themselves enter the queue with the source and mismatched field indicated.
Reconciliation runs every 15 minutes and takes the operator about 15 minutes a day: what remains is exception review instead of a continuous pass. The share of discrepancies dropped to 0.3%, and these are now real discrepancies in supplier data, not input errors.
The classes "duplicate request" and "missed cancellation" disappeared — both operations pass key validation. The queue is closed on the day of receipt, and every rejection leaves a trace: who changed the record, when, and why.
What to do if a process is already covered by a ready-made system
A purchased system rarely covers the whole contour: a typical module keeps records, but does not know your exceptions — non-standard approvals, manual reconciliations, fields that simply do not exist in its model. Throwing away a working solution for this is expensive, so the fork is resolved by three options.
| Option | When it fits | Limitations |
|---|---|---|
| Embedding into the ready-made system | The logic fits its model: settings, rules, an additional module | Vendor updates break customizations, and some model limitations cannot be circumvented |
| Add-on over the accounting system | Accounting remains the source of truth, but you need your own interface and processes | Stable data exchange is required; schema divergence is caught on every release |
| Separate tool alongside | The process is weakly connected to accounting, exchange goes by events | Two interfaces for employees, duplication of reference data |
The choice is determined by the point where the logic originates. If the rules live inside the accounting system and transactions depend on them, we embed or add on, but we do not copy data.
Integration without migration is built on reading through an export or replica and writing only via standard methods: integrity is not broken, and the tool can be disconnected without traces in accounting.
When a process in the purchased system is described formally but in reality goes differently, it is cheaper to replace part of the contour: leave accounting where it works, and move the disputed area into your own tool on Tooljet.
Our engineers fix module boundaries, permissions, and exchange points before development — otherwise the add-on turns into eternal synchronization of two truths.
Concerns about integrations, access, and maintenance
Before starting, the same questions almost always come up: how the tool will be connected to the accounting system, how to separate permissions between roles, and what will happen after code handover.
The architecture depends on the answers, so we fix them before the first line of implementation, not at acceptance.
How will the internal tool connect to the accounting system?
The accounting system remains the source of truth: reference data and employee lists are read from it, not duplicated by manual spreadsheets.
Synchronization goes by events, with retries and a discrepancy log — if a record did not arrive, it will go into reconciliation rather than be lost. Reverse writing is possible only for agreed operations and a separate service account with reduced permissions.
How are access permissions separated?
Roles are inherited from directory groups: a person sees only their own objects, and access is granted by group membership, not by a manual exception table.
Permission checks sit on the server and apply to exports, reports, and programmatic calls — otherwise restrictions are bypassed through a direct query. Moving an employee between departments changes the set of groups, and access is rebuilt automatically.
What happens after handover — will we remain dependent on the contractor?
We hand over the source code, data schema, migrations, environment descriptions, and deployment instructions: the build is reproduced from the repository without our infrastructure.
For maintenance, we agree on regulations — dependency updates, a regression check set, and a rollout window. Support can remain with us, or you can run it with your own team: we conduct knowledge transfer and stay in touch on critical issues.
Let's discuss the task: which internal processes to start with
Starting an internal tool comes down not to the platform, but to choosing the first process. We begin with one area where manual work consumes the most time and there is an owner of the result: requests, approvals, accounting, preparation of regular reports.
Such an area gives a tangible effect in the very first release and does not require rebuilding accounting entirely.
To come back with a timeline estimate and work plan, not general words, we need at minimum:
- one or two candidate processes that today live in spreadsheets, email, and messages;
- examples of real forms, documents, and exports — they reveal the data structure and relationships between entities;
- an employee who performs the process every day and can explain its bottlenecks in half an hour;
- constraints: which systems must not be touched and where data must remain in the internal contour;
- read access to the accounting system or exchange interface to test hypotheses on live data;
- a readiness criterion — what exactly must change for the tool to be considered working.
The order of work is predictable: we review the process, fix the boundaries of the first release, assemble a prototype on Tooljet and real data, check it together with executors, and bring it into the working contour. Then we build up roles, notifications, and exports — the configuration remains with you.
Describe the task in a couple of paragraphs or send an anonymized export — we will discuss it and come back with an estimate and a phased work plan, including the order of next steps.