Software
Web applications
and mobile apps built to order
Some processes cannot be squeezed into a spreadsheet or an off-the-shelf program. In those cases a tool that fits the way your company really works does better than reshaping the company around the software.
When a custom application makes sense, and when it is overkill
A custom application is one of the more expensive IT investments a company can make, so we tell you plainly when it does not pay off. If an off-the-shelf subscription program can handle the process and the only thing that bothers you is how it looks, there is no reason to build something from scratch.
The point at which your own tool starts to pay off is usually easy to spot. Someone in the company retypes data from one system into another every day. Orders arrive by email and someone enters them into the warehouse system by hand. Sales staff keep their own versions of the price list in files on their desktops. Customers phone to check the status of an order because they have no way of checking it themselves.
In each of these situations a person does by hand what a tool could do. The work comes back every day, and retyping data easily leads to mistakes.
What we build most often
We build business tools that handle a specific process in a company and that staff or customers use every day. We do not make games or research projects.
- Client portals: orders, documents, history and payments in one view
- Booking systems for appointments, rooms, equipment and services
- Product configurators with automatic pricing and a PDF quote
- Internal document workflow and approval systems
- Warehouse applications that work with handheld data terminals
- B2B portals with individual price lists and credit limits
- Calculators and sales tools embedded on your website
- Integrations that connect systems which do not talk to each other
Some of these can be built as an extension of an existing website or shop. See online shops and ERP integrations. We check this route first, because it is usually cheaper and faster.
Web or mobile application: which to choose
We usually recommend starting with a web application. It runs in the browser on any device, with no installation and no waiting for app store approval. An update reaches all users at once.
A native iOS and Android app makes sense when it needs things a browser cannot provide: working offline in the field, push notifications, constant access to a barcode scanner or a presence in the app stores. Without those needs, a native app mainly raises the cost of building and maintaining it.
The third option is an app you install from the browser (PWA). It has an icon on the phone's home screen, can work offline and is built from the same code as the web version. It can be a sensible compromise between a web app and a native one.
| Solution | When to choose it |
|---|---|
| Web application | Work at a computer, access from many locations |
| Installable from the browser (PWA) | Field work that needs offline mode and an icon on the phone |
| Native iOS and Android | Camera, background GPS, push notifications, required presence in the app stores |
Analysis before coding: the quote depends on it
In software, the most expensive features are the ones users never end up using. That is why we start with one or two weeks of conversations and observation: who carries out the process, in what order, where they get their data and what they do when something goes wrong.
These conversations produce a document with a list of features, a description of user roles and screen sketches. Only on that basis do we price the work and set the schedule. The document stays with you whether or not you decide to continue working with us. You can take it to another company and compare offers on the same basis.
Sometimes the analysis ends with a recommendation not to build the application, because the problem turns out to be organisational rather than technical. In that case we say so in the document.
You know the cost and schedule before you sign the contract, not halfway through the work.
Work in short stages, with a working version every two weeks
We work in two-week stages and after each one we show you a working part on a test environment. So you never spend six months seeing nothing, only to find at the end that half of it works differently from what you imagined.
This has two advantages. First, you see progress and can react while a change is still cheap: a correction after two weeks costs far less than rebuilding a finished system. Second, we agree the order of work together, so the most important features are built first and can be used before the project ends.
The test environment is kept separate from production throughout the project and after launch. We check every later change on it before it reaches users.
What we build with, and why
We write the backend in Python (FastAPI) or PHP (Laravel), depending on what the system needs to integrate with and what the client already maintains. The databases are usually PostgreSQL or MySQL, and in projects linked to warehouse systems also Microsoft SQL Server. You can read more about this under MS SQL databases.
We keep the frontend as light as possible. Not every application needs a heavy framework: a simple panel without unnecessary libraries runs faster and costs less to maintain. We use React or Vue for complex interfaces with many states.
We choose popular technologies so that another team can take over the project in the future.
The source code stays with you
When the project is finished, we hand over the full source code together with documentation and access to all environments. We charge no licence fees for using the application and use no lock-ins that would mean rewriting the system from scratch if you change provider.
This is worth checking in every offer. An application provided on a subscription that stops working when the payments end can be a fair arrangement if the contract describes it clearly. The problem arises when there is no such clause. Warning signs in an offer:
- A contract with no clause on handing over the source code
- Hosting only with the provider, with no option to move it
- No technical documentation after the work is finished
- Accounts in third-party services registered to the provider
- A fee for every content change, even a single sentence
What happens after launch
After launch the application keeps changing. Regulations change, and so do the systems it integrates with and the way the company works. That is why we offer ongoing maintenance: security updates, uptime monitoring, backups and a set number of hours for small changes.
Maintenance is not compulsory. You can take it over yourself or hand it to another company, because once the project is finished the code, documentation and access are on your side. If we maintain it, small fixes go faster because we know the project inside out.
Fast, no-nonsense work. These guys know what they are doing.
What the cost of an application depends on
Giving a price without analysis would be guesswork. The cost depends on the number of features and user roles, integrations with other systems and any requirements for offline work or a native app. We price every project individually, after the analysis. Below are typical types of project. The first working version usually covers a smaller scope than the target system.
| Type of project | Example |
|---|---|
| Single-purpose tool | Calculator, configurator, form with logic |
| Internal panel | Order workflow, bookings, simple CRM |
| System with integrations | B2B portal, client portal connected to ERP |
| Native mobile app | iOS and Android with a backend |
We invoice in stages, tied to the acceptance of each completed part. We do not take the full amount upfront, so you never pay for something you have not yet seen working.
Working together
How we work together, step by step
Conversation and initial assessment
You describe the process, and we tell you whether a ready-made tool could handle it more cheaply.
Analysis and document
Conversations with the people who do the work, a feature list, screen sketches, a quote.
Interface design
A clickable prototype on which we check the screen layout before coding.
Building in stages
Every two weeks, a working part on the test environment for you to review.
Testing and training
Tests with future users, fixes, training and a user guide.
Launch and maintenance
Production deployment, monitoring, handover of code and access.
Questions
Frequently asked questions
It depends on the scope: a simple tool is built faster than an internal panel, and a system with integrations takes longest. We set the exact schedule after the analysis. We aim to deliver the first usable version as early as possible, so it can be used while the rest of the work continues.
Yes, and we usually recommend it. The first version covers one process, and we add the rest based on what users actually need in their daily work.
You get the source code, documentation and all access, so another company can realistically take over the project. We use no licences or lock-ins that tie you to us.
Usually, yes. We integrate applications with Subiekt and Insoft systems, among others. The scope depends on the data exchange options a given system offers. We describe the details under ERP integrations.
On our server, on yours or in the cloud, whichever you prefer. With sensitive data, a server in Poland is the more common choice; with large swings in load, the cloud.
We help prepare the technical side of the application: encryption, access control, logs, deleting data on request. You prepare the legal documentation on your side, usually with a data protection officer, and we provide them with a technical description.
Related services
What else may be useful
Your city
Web applications in your city
For each of these cities we have a separate page describing the local market and how we work with companies there.
Describe the process that takes up the most time today
Tell us briefly what is done by hand in your company. Within 24 hours we will reply whether a ready-made tool can handle it and, if not, what the cost of your own would depend on.