1. An internal tool, or a public product?
An internal app serves your own people. You know them, you can train them, and a small rough edge in the interface stops nobody. Most of the budget therefore goes into logic and connections to other systems. A public product has to guide a stranger with no manual, handle GDPR consent, pass app store review, offer customer support and cope with growth. The same feature costs more because of everything around it.
A real example: FoxFix started as one car service's internal system, and over time we made it ready for other companies in the industry. Slevy a Akce was a public app from day one, so consent, notifications and both app stores were part of the work from the start.
2. Integrations: where most of the work hides
Connecting accounting, a CRM, a payment gateway or public registries is always a small project of its own: a different interface, different errors, different rules. In our projects that meant, for example, an accounting system, a CRM, public registries, electricity market prices or a payment gateway. Each such integration adds days to weeks of work. It is also usually where the biggest time saving comes from, because it removes retyping.
- List the tools the app must talk to, and find out which of them have an API.
- Separate what must work from day one from what can come in phase two.
- Expect integrations to need maintenance after launch too.
3. How many platforms
Web, iOS and Android from one codebase are no longer a problem. Standard tools handle it and we use them. What remains is preparing releases for the app stores, App Store and Google Play review, testing on phones and two sets of rules. A mobile app therefore adds roughly a third to a half of extra work on top of the web, not double. ZEUS Core has a website and a mobile app on the same data, so new features reach the app without doing the work twice.
4. AI: the demo is cheap, reliable operation costs more
Showing an AI chatbot takes an afternoon. Deploying AI so it genuinely saves the company time takes clear rules: what it may do, where a person confirms the result, servers in the EU and ongoing quality checks. On top of that come fees for using the AI model, which grow with the volume of work. The good news: in a well-designed deployment, AI running costs are usually a fraction of the work they save.
5. A one-off project, or a monthly collaboration
A one-off delivery with an agreed scope fits when the brief is clear and nothing fundamental changes after launch. Think of a website, an enquiry page or a single-purpose tool. Monthly stages make sense for systems that grow with the business. FoxFix and ZEUS Core have grown with us for over a year, each month adding a part that real day-to-day work called for. The monthly payment is lower than one big upfront investment, and you steer the total cost by your priorities.
How to prepare for the first meeting
You don't need a specification. Just answer four questions: who the app is for (internal or public), what it must connect to, which platforms it should run on and whether it is a one-off project or a long-term product. That is exactly what our contact form asks. On an intro call we clarify the brief, then propose an approach and a cost estimate that fits your particular project.
After the initial analysis we usually start with a prototype. It runs on your data and shows whether it is worth continuing before you commit a larger budget.