Bespoke software consultancy
We build the software you can’t buy.
Grigori Solutions designs and builds custom software for Australian organisations with a problem off-the-shelf tools haven’t solved. We scope it small, build it quickly and keep it confidential.
- Bespoke software
- Systems integration
- Edge computing
- Applied AI
- Workflow optimisation
- Short loops
- On site or remote
- Inside your environment
- Australia wide
- Built to hand over
The short version
Some problems are too specific for a product and too urgent for a programme.
When software nearly fits, the gap becomes somebody’s job: a spreadsheet kept beside the system, figures keyed in twice, one person who knows how it all joins up.
We build the piece that closes the gap. It might be a complete application, a service between two systems, software on a device at a remote site, a model put to work on your own hardware, or an automated step where a person used to sit in the middle. We keep it small, so you see working software early and can correct us while correction is cheap.
Not all of this work is ours to talk about, so this site tells you how we work, not who we work for.
01Capabilities
What we build.
The main areas of work. A problem rarely sits neatly inside one, so expect a job to draw on several.
Bespoke software
A complete tool that does one job and runs on its own.
Applications that install on your machines, run without a network if they have to, and keep their data where you put it.
Each application carries what it needs. It doesn’t assume a cloud account, a licence server or a permanent network link unless you want one. The form follows the user, whether that is a desktop tool for a specialist, a web application on an internal server or a command-line utility that runs on a schedule. Once installed, it is built to keep running without us.
Kinds of work
- Desktop and field applications that work offline
- Internal web applications hosted on your own servers
- Data capture, review and reporting tools
- Replacements for the spreadsheet that became a system
- desktop
- web
- command line
- offline-capable
- local data
- installers
Systems integration
Between systems that were never meant to meet.
Software that sits between the systems you already have and moves data from one to the other, converted on the way, so nobody has to carry it across by hand.
Integration work is mostly the cases nobody wrote down: the field that is sometimes empty, the message that arrives twice, the system that goes quiet overnight. We build middleware that translates between formats and protocols, queues what it can’t deliver, retries, and records what it did, so a failure can be traced to where it happened. The systems stay. The retyping goes.
Kinds of work
- Adapters between an older system and a newer one
- APIs in front of systems that were built without one
- Message queues and scheduled data transfers
- Format and protocol translation, with validation and an audit log
- APIs
- adapters
- message queues
- protocol translation
- legacy systems
- audit logs
Edge computing
Compute where the data is made, link or no link.
Software for small machines close to the work: at a remote site, in a vehicle, beside the equipment. It processes data on the spot and, when there’s a link, sends on what matters.
At the edge the hardware is small, power is limited, the network comes and goes, and nobody is nearby to restart anything. So the software processes locally, holds its results until a link appears, and is designed to synchronise without losing records or sending them twice. It connects to sensors, cameras and equipment at one end and your central systems at the other. We also plan how it gets updated once it’s somewhere awkward to visit.
Kinds of work
- On-device processing of sensor and camera data
- Store-and-forward synchronisation over unreliable links
- Gateways between field hardware and central systems
- Remote update and health monitoring for devices in the field
- on-device
- store and forward
- low power
- intermittent links
- telemetry
- remote update
Applied AI
Models put to work inside the systems you already run.
We fit language, audio and vision models into your processes, where they do a defined job and a person can check the result. Where it’s needed, they can be set up on your own hardware with no outside connection.
A model is a component, not a product. It is useful when it has a narrow task, the right information in front of it, and something downstream that checks its work. We do that engineering, including the tests that show how often the model is wrong and a clear way for a person to overrule it.
Kinds of work
- Search and question answering over your own documents
- Extraction of structured data from documents and images
- Transcription and translation of speech and text
- Classification, triage and routing steps inside an existing workflow
- Locally hosted models for environments with no outside connection
- language models
- natural language processing
- audio
- computer vision
- local inference
- retrieval
- evaluation
- human review
Workflow optimisation
Find where the work waits. Fix that part.
We follow a piece of work through your organisation as it’s actually done, find where it waits or gets done twice, and build what removes the delay.
We start by watching the work, not a diagram of how it’s meant to go. Delay tends to sit in the handovers: something waits in an inbox, is keyed into a second system or stalls on an approval that has become a formality. We map the process as it runs, agree which steps matter, then automate, combine or remove the rest. Sometimes the answer is to delete a step and write no software, and we’ll say so.
Kinds of work
- Process mapping with the people who do the work
- Automation of repeated manual steps and double entry
- Approval, routing and notification tools
- Queues and dashboards that show what is held up
- process mapping
- automation
- handovers
- double entry
- approvals
- reporting
02Approach
Small scope. Short loops.
Speed comes from deciding what not to build. From the scope onward, each step is planned to end with something you can inspect, so you can decide whether we go on.
Listen
You describe the problem and we ask questions until we both understand it.
We want to know what happens now, who it happens to and what can’t change. This can be done under a confidentiality agreement, and without written detail if you prefer. If we’re not the right people for it, this is where we say so.
Scope
We write down the smallest thing worth building.
The scope says what the first version does, what it leaves out, what it connects to and how we’ll both know it works. It lists the assumptions it rests on, so a later change is visible as a change, and it is short enough to read properly. Access, data and disclosure are settled here, before any code.
Build
We build in short loops and aim to show you running software at the end of each.
The first version is rough but real: it runs on live or representative data and does part of the job. You tell us what’s wrong with it, and the next loop works on that and adds the next part. Where your rules allow, those loops can run in your environment from the start, not only in ours.
Fit
We put it where it has to run, and test it there.
Software is finished when it works in your environment, with your data and your people. We install it under your access controls and your change process, test it against the cases we agreed and the ones real use turns up, and fix what falls within the scope. The people who will use it are shown how by the people who built it.
Hand over
You take it on, with what you need to run it without us.
Your team gets the software, its documentation and the notes on why it was built this way. We can hand over source code and build instructions too, so that your own people or another supplier could carry it on. If you’d rather we kept looking after it, we can do that.
A larger problem is handled the same way, one piece at a time, with each piece working before the next begins.
03Sensitive work
Some work can’t be discussed. So we don’t.
We treat discretion as an ordinary requirement and meet it with plain habits. These are ours. Where your organisation has stricter rules, tell us at the start and we’ll say whether we can meet them.
Agreement first
A confidentiality agreement can be in place before you tell us anything that matters. If your organisation has its own, send it and we’ll work from that.
Nothing published
We don’t publish client names, logos, quotes or case studies. Your work is not our marketing, and your name is yours to disclose.
Few hands
We keep your material to the people doing the work, and agree who they are before we start. We ask for the least access that will do, and build on synthetic or masked data where we can.
On your systems
We can work entirely inside your network, on your machines, under your access controls. When we work that way, your data has no reason to leave your systems, and we take nothing out without your approval.
Disconnected if required
Where a system has no outside connection, we build for that: no cloud services and no external calls. Models and dependencies are carried in and run locally.
Clean exit
When the work ends we hand back access and return or delete your material, as you direct. The software and its documentation stay with you.
There are no case studies here to go on, so we keep the first piece of work small enough to judge us by.
04Reach
Australia wide.
We take on work in any state or territory, in a capital city or a long way from one. How we do it depends on where the problem is and where the work has to stay.
- NSWNew South Wales
- VICVictoria
- QLDQueensland
- WAWestern Australia
- SASouth Australia
- TASTasmania
- ACTAustralian Capital Territory
- NTNorthern Territory
On site
We come to you when a process has to be watched as it runs, when software has to be fitted to a piece of equipment, or when the system can’t be reached any other way. Some things only make sense once you’ve stood next to them.
Remote
Most of the build can be done at a distance, over channels you approve, and shown to you running wherever you are.
Inside your environment
When the work can’t leave the building, we can do it in the building, under your rules, connected or not.
05Contact
Start with the problem.
A few plain sentences are enough: what happens now, and what you need to happen instead. We don’t need a brief or a budget.
A person reads each enquiry and replies by email, including when the answer is that we can’t help. What you send is used for that reply and for nothing else.