Custom systems
Built around your workflow and requirements instead of forcing your team to change how they work to fit generic software.
Services · Custom Software
Custom software and web systems built around how you really work
For work that off-the-shelf software can't handle, we build internal systems, customer-facing systems, dashboards and integrations between platforms — starting from what the real problem is, before asking which features you need.
- Web systems and back office
- Dashboards and reporting
- APIs and integration
- Support after launch
Real screens from AIVEQ's web system, built by our team
What we build
We don't write code to a feature list
Before agreeing what to build, we ask what the real problem is, who the users are, what outcome the system should change, which data is needed — and, most importantly, what should not be built.
Web systems for internal teams and customers
Manage work, customers, data, documents and internal processes in the browser, on any device.
Dashboards and reporting
Bring data from several sources into views that answer real questions for leaders, teachers, parents and teams.
APIs and system integration
Connect existing systems, external platforms and new services so data flows without re-entry.
Before you decide
When to build custom software — and when not to
Straight advice from a team that both buys off-the-shelf tools and builds its own systems.
Build your own when
- The way you work is a strength that off-the-shelf software cannot support
- Your team re-enters the same data in several systems every day
- You need reports that answer questions specific to your business
- You need to connect several platforms that don't talk to each other
Don't build yet when
- Off-the-shelf software already covers your core needs
- It is not yet clear who will use it and for what — start with a Discovery Sprint
- The goal is simply to tick off a feature list without measuring the effect on users
Before you hire
How to choose a software development company: 6 questions to ask before you hire
A system your organisation uses every day stays with you far longer than the contract. These questions help you pick a team whose system gets used, not just delivered.
Do they ask about the problem first, or only for a feature list?
Systems built only from a feature list tick every box and nobody wants to use them.
At AI.ac.thWe don't write code to a feature list. Before agreeing what to build, we ask what the real problem is, who the users are and what outcome should change.
Will they tell you if off-the-shelf software is the better deal?
Some work should not be custom-built. A team that never says so sees your project as just a sale.
At AI.ac.thIf off-the-shelf software already covers your core needs, we will tell you plainly not to build.
Do they have systems of their own in daily use?
A slide is not the same as a system people use every day. Ask to see the real thing before you decide.
At AI.ac.thAIVEQ's web system and dashboards serve both learners and parents — the screenshots on this page are real.
Will you see real work in rounds?
Waiting to see everything at the end turns small misunderstandings into large rework.
At AI.ac.thWe ship in rounds you can try before it is finished, with test documentation and a log of what was fixed.
How well will it connect to your existing systems — and is that checked first?
Integration problems discovered mid-project are a major reason budgets and timelines grow.
At AI.ac.thOur first step is to check how open your existing systems are, then design so data flows without re-entry.
Who maintains it after handover, and is there a guide?
A system with no one looking after it and no guide slowly gets abandoned for spreadsheets.
At AI.ac.thWe support the system after launch, follow real usage in the first weeks and hand over an administrator guide.
How we work
Delivered in rounds — see the real thing before it's finished
Every step has a clear deliverable, so you always see where the project stands.
Understand the problem
We talk to the people who will actually use the system, not just the people commissioning it, map the current process end to end, and separate the real problem from its symptoms.
What you getA brief covering the problem, the users, the outcomes that must change — and a list of what we recommend not building.
Design the system
We design the data structure, access rights and key screens, starting from the tasks users do most often — not the prettiest screen.
What you getA clickable prototype, the data structure, and a development plan split into rounds.
Build and test
We ship in rounds you can try before it is finished, because what users say when they see the real thing is always different from what they say about a picture.
What you getA system tested with real users, with test documentation and a log of what was fixed.
Launch and improve
Launch day is not the end. We follow real usage in the first weeks, fix what gets in the way, and decide what to build next from what the data shows.
What you getA live system, an administrator guide, and a proposal for the next round based on usage data.
Start small
Discovery Sprint · 2 weeks
Step one of every software project, available on its own.
Not ready to commit to the whole project? Start with step one alone. At the end you will know what to build, what it should cost and how long it will take.
Talk about a Discovery SprintWhat happens in the two weeks
- Interviews with real users
- A map of how the work is done today
- Requirements ranked by what must come first
- A prototype of the key screens
- A budget and timeline estimate
- A straight answer on what not to build
- Delivered as documents any team can build from — no lock-in to us
FAQ
Frequently asked questions
What people ask before hiring a software development company
Where should I hire a software development company?
Choose a team that asks about the problem before the feature list, tells you plainly when off-the-shelf software is the better deal, has its own systems in daily use to show you, ships in rounds, checks how your existing systems connect before starting, and has a plan for after handover. See the six questions before you hire.
Build custom software or buy off-the-shelf — which is better value?
If off-the-shelf software already covers your core needs, buying is usually the better deal. Custom software pays off when the way you work is a strength that generic software cannot support, or when your team re-enters the same data in several systems every day. If we think you should not build, we will tell you.
Can it connect to the systems and platforms we already use?
Yes, through APIs and integrations. Our first step is to check how open your existing systems are to connection, then design so data flows between them without re-entry.
Can you build dashboards for management?
Yes. A good dashboard answers the questions its users actually ask instead of showing every number. One example of our work is the AIVEQ parent centre, which shows what a child is practising, how they are progressing and where they need support next.
We have no in-house IT team. Who maintains the system?
We do. We follow real usage in the first weeks after launch, fix what gets in the way, and hand over an administrator guide with a proposal for the next round based on usage data.
How much does custom software cost and how long does it take?
It depends on scope and the systems it must connect to. Start with a 2-week Discovery Sprint to get a prototype of the key screens, a budget estimate and a timeline you can rely on before committing to the whole project.
What should we prepare before talking to you?
Just tell us the problem, who the users are and what you want to change. No requirements document needed. See the contact page.
Our services
Related services
Tell us about your project
No spec needed — we are good at starting from a brief that isn't clear yet.