Start with one team
An app for one team needs fewer approvals than a change to the core platform, and it shows results within a few months, not years.
A defined first release
Enterprise software development and integration with existing systems
Get the internal tool your team needs, or replace an old system one process at a time
In large organizations, the tool one team needs often waits months behind core platform projects, while staff work around an old system with spreadsheets. We build focused internal applications, prototypes you can test with real users, and replacements for parts of older systems. The old system keeps running while the new one takes over one process at a time, connected through an API. Your IT and security teams can review every step.
- Internal apps for one team or one process
- Prototypes tested with real users before a wider rollout
- Old systems replaced one process at a time
- Code, documentation and accounts handed to your IT
Why it works.
-
01 -
02 Replace in slices, not in one go
Replacing an old system all at once is where budgets and timelines go wrong. We move one process at a time while the old system keeps running behind an API.
Lower risk
-
03 Prove it before you scale it
A working prototype in the hands of real users answers questions a long specification can’t. You decide on the wider rollout with evidence.
Prototype first
-
04 Fit your IT rules
Single sign-on, your cloud, your security review and your documentation standards. Code and access are handed over to your team.
Works with your IT
Replacing an old system without switching it off.
We design staged replacement around the existing system’s capabilities. Before each stage, agree synchronization, a cut-over rehearsal and conditions for returning to the old process.
- The old system keeps running Nothing is switched off on day one
- An API layer in front of it A thin layer reads and writes the old data, so new tools don’t touch the old database directly
- A new app takes one process Approvals, requests or reporting, used by one team first
- Rules keep both in step Checks compare records and send discrepancies for correction
- Users run both side by side For a few weeks, with the old screen as a fallback
- The old screen is switched off Then the next process, until the old system has nothing left to do
What we’ve learned.
From the projects we’ve built in this area.
-
01 Verify one transfer between systems first.
Choose a specific operation, such as handing an approved job to the ERP. Verify the interface, permissions, errors and repeated transfers. Use that evidence to scope further integrations.
-
02 Rewriting everything at once is the riskiest option.
A full replacement means a long stretch without a usable result and a single cut-over day that has to go right. Moving one process at a time gives you something usable every few months and a way back at each step.
-
03 The hard part is the data, not the screens.
Old systems carry years of exceptions, half-used fields and rules nobody wrote down. We spend the first weeks reading the data and talking to the people who use it, because that is where the real requirements are.
-
04 Bring IT and security in at the start.
Single sign-on, hosting, access reviews and penetration tests take time in a large organization. Agreeing them in week 1 stops a finished app from waiting months for approval. Our app for Slovenská sporiteľňa passed the bank’s penetration test before launch.
-
05 AI helps read the old system, people still decide.
We use AI tools to read old code, map fields and draft migration scripts, with a developer responsible for every result. Once the old data sits behind an API, AI assistants can also answer questions from it, through standards such as MCP (Model Context Protocol).
What we can build.
-
Focused applications
- Internal tools for one team or process
- Approval and request workflows
- Prototypes for testing with real users
- Apps that run alongside the core platform
-
Modernization
- Step-by-step replacement of old systems
- API layers in front of old databases
- Data migration and clean-up
- Rebuilds of slow or unreliable internal tools
-
Enterprise requirements
- Single sign-on and role-based access
- Audit logs of who did what and when
- Deployment to your cloud or your servers
- Documentation and handover to your IT team
-
AI on internal data
- Assistants that answer from internal records
- Reading and sorting documents
- Private AI on self-hosted models when data can’t leave
- Connections through APIs and MCP
Rewrite, buy a platform, or replace step by step?
Three common ways to deal with an old system. None of them is right everywhere.
| Full rewrite | Standard platform | Step-by-step replacement | |
|---|---|---|---|
| First useful result | At the end | After setup | Within months |
| Risk on cut-over day | High | High | Low |
| Fits your own processes | Yes | Partly | Yes |
| Old system keeps working meanwhile | Partly | Partly | Yes |
| Can stop or change course midway | No | No | Yes |
| Budget | One large commitment | Licences and setup | In stages |
Projects like this.
What we’ve built for clients in this field.
-
Enterprise app Slovenská sporiteľňa
Custom event networking app · Slovakia
The problem
The bank needed a branded app for an event, with participant profiles, a schedule and networking features, that met its security requirements.
What we built
- Participant profiles and directories
- Schedule and navigation
- Messaging and networking between participants
- Bank-level penetration test before launch
What changed: An event app with profiles, schedules, navigation and messaging that passed the bank’s penetration test before launch.
How the first version comes together.
A typical timeline. We confirm yours after the project workshop.
- 1
Day 1
30-minute callWe talk through the system, who uses it and what hurts. You leave with what to build first and a rough price.
- 2
Week 1
Workshop and data reviewWe map the process with the people who run it, look at the old data and agree hosting and security with IT. Then a fixed price, before any build starts.
- 3
From week 2
Build in 2-week stagesA working demo every week, on test data first, then on an anonymized copy of real data where your rules allow.
- 4
Launch
One team, side by sideThe new app runs alongside the old one for one team. You own the code, the repositories and the accounts.
- 5
Then
The next process3 months of free bug fixes, then the next slice, with us or with your own developers.
Case studies.
Systems we’ve built that are close to this one.
-
One platform to replace older student systems
College-access platform for recruitment, scholar success, and alumni tracking
Read the case study -
Candidate and employee management
Workforce platform for temporary staffing, recruitment, compliance checks, and payroll administration
Read the case study -
Slovenská sporiteľňa: Event networking app for a bank
Event networking app for a bank
Read the case study
Further reading.
- From AI pilot to production: why pilots stall and how to avoid it Why AI demos impress but pilots stall, what has to change before people rely on an AI system every day, and a checklist for moving a pilot into production. Read the article
- What is MCP? The Model Context Protocol explained for companies What the Model Context Protocol is, how it connects AI apps to your CRM, files and databases, when you need it and what to secure first. Read the article
- Self-hosted LLM or API? Privacy, quality and cost compared Public API, EU-hosted API or an open-weight model on your own servers: how they compare on privacy, quality, cost and effort, and when each one fits. Read the article
Questions people ask.
Do you work with large organizations?
Yes, usually with one department or team at a time. That can be an internal application, a prototype or the replacement of part of an older system. We work within your IT, security and procurement rules.
Can you replace a legacy system without stopping the business?
We plan the switch in stages and verify overlap options before building. Agree the source of valid records, reconciliation, a cut-over window and conditions for returning to the previous process. Zero downtime cannot be promised without understanding the original system and its dependencies.
Can it integrate with our existing enterprise systems?
Usually yes, through APIs, database connections, message queues or file exchanges. Single sign-on with Microsoft Entra ID or Google Workspace is standard. Sometimes the safer choice is to keep a new tool separate and sync only the data it needs.
Where will it be hosted?
Wherever your rules require. That can be your own cloud account on AWS, Azure or Google Cloud, your own servers, or hosting we set up for you. Either way, the accounts are yours.
What does a project cost?
An internal tool for one process, connected to 1–2 systems, costs €5–10k. A connected system with 10+ features costs €10–30k, and replacing older software with many integrations starts at €30k. We agree a fixed price after the project workshop, before any build starts.
How fast can something useful ship?
Our past projects took 6 weeks to 3 months to reach a first version. Internal security reviews and approvals can add time, so we start them in the first week rather than at the end.
Can we use AI on internal data without it leaving the company?
Yes. One option is a provider with EU hosting and a contract that excludes training on your data. The other is an open-weight model such as Llama, Mistral or Qwen, running on your own infrastructure. Which one fits depends on your data rules and how much you’ll use it.
Who maintains it after launch?
Your choice. You get the code, the documentation, the repositories and the accounts, so your own team can take over. We fix bugs free of charge for 3 months, then offer optional monthly support.
Does integration require replacing the whole ERP?
No. If the ERP handles accounting or inventory well, we can add a portal, approvals or data transfers. First we check specific API operations, permissions and licenses. Replacing the entire ERP is a separate project with its own discovery.
How do you hand the project to our IT team?
Agree repositories, access, deployment documentation, integration interfaces and operating procedures. Acceptance includes running the agreed scenarios and defining responsibilities after launch.
Which process is stuck in an old system?
Tell us what the system does and who depends on it. We’ll suggest the first slice to replace, or the internal tool to build, and what it would cost.
JurajCEO, QikBuild
You leave the call with
- What we would build first
- A rough price range
- Whether custom software makes sense for you
Or write to hello@qikbuild.com