Good projects start with fewer unknowns.

We start with the business problem, not with a technology shopping list. The first conversation is about what is happening today: which process is slow, where information is copied manually, what customers or employees struggle with, which systems are already in place and what outcome would make the project worth paying for.

From there we turn the problem into a workable scope. For a smaller website or automation, that may be a concise specification with deliverables, timeline and price. For a larger application, CRM, ERP or multi-system workflow, we may first map users, permissions, data flows, integrations, edge cases and rollout priorities. You receive a clear proposal before paid development begins, so both sides know what is included, what is not included and how success will be judged.

You do not need to arrive with a perfect technical specification. What helps most is operational context: what your team does today, which tools are involved, what breaks or wastes time, approximately how often the process happens, who uses the system and what must absolutely not go wrong.

Screenshots, example files, current forms, anonymised sample data, process notes and access to a test environment can make estimates more precise. If you already have a feature list, we will challenge it where necessary. A long list of requested features is not automatically a good scope; sometimes three well-designed workflows solve the business problem better than twenty disconnected features.

There is no honest universal duration because a focused script and a business-critical platform are different products. A small automation can sometimes be designed, built and tested in days. A premium marketing website may take several weeks once copy, design, responsive behaviour and integrations are included. A custom web or mobile application usually runs across multiple milestones and can take several weeks to several months depending on scope.

The biggest variables are integration complexity, data migration, number of user roles, approval cycles, external API limitations, security requirements and how quickly feedback is available. We therefore estimate in ranges and milestones rather than pretending every project fits a fixed calendar. The objective is not to stretch a project; it is to release something dependable without creating technical debt that costs more later.

Yes — and in many cases we recommend it. If one repetitive process is costing the team several hours every week, it can be smarter to automate that workflow first, measure the result, and then decide whether the surrounding system deserves a larger investment.

A smaller first phase can be a script, internal dashboard, prototype, document generator, API bridge or one critical module of a larger application. We design that first phase so it can teach us something useful and, where sensible, become part of the future system rather than disposable work. This reduces risk and makes budget decisions easier because the next investment is based on real usage instead of assumptions.

We work with visible milestones. Instead of disappearing for weeks and presenting a finished product at the end, we break the work into reviewable stages: architecture, design direction, core workflows, integrations, testing and launch. The exact rhythm depends on the project, but the principle is constant — feedback should arrive while it is still inexpensive to act on.

If priorities change, we document the change and explain the effect on scope, price and delivery before implementing it. Small clarifications are part of normal development. A new workflow, major redesign or additional integration is different and should be treated transparently as extra scope. That protects both sides from the common problem where a project quietly doubles in complexity while everyone pretends the original budget still applies.

The strongest candidates are repetitive processes with predictable inputs, clear rules and a meaningful volume. Typical examples include moving data between systems, validating forms, generating PDFs or reports, processing spreadsheets, renaming and organising files, sending structured notifications, updating CRM records, synchronising stock, monitoring statuses, collecting data from APIs and triggering follow-up actions.

We also build multi-step workflows where software performs the routine work and a person only handles exceptions or approvals. The goal is not to automate everything blindly. A good automation removes repetition while keeping human judgment exactly where it creates value. During discovery we look at frequency, error cost, time spent and operational risk to decide whether automation will actually produce a worthwhile return.

Usually, yes. If a system offers a documented API, webhook, database interface, export/import mechanism or another permitted integration method, we can often connect it to the rest of your workflow. That might mean sending website leads into a CRM, synchronising orders with stock, generating documents from ERP data, pushing notifications to a team tool or combining data from several services into one dashboard.

The important part is checking the limitations early. Some third-party systems have rate limits, restricted APIs, expensive enterprise connectors or authentication rules that affect the solution. We investigate those constraints before promising an integration. Where direct integration is not possible, we discuss safe alternatives rather than relying on a fragile workaround that could break without warning.

Reliable automation is more than a script that works once on the developer’s computer. We design validation, logging, predictable error handling, duplicate protection, permissions and recovery paths around the business risk of the process. If an action is sensitive — for example issuing a financial document, changing inventory, deleting records or sending something externally — we can add approval checkpoints or dry-run modes before the final action occurs.

We also define what should happen when an external service is unavailable, data is incomplete or an unexpected format appears. The right level of protection depends on consequence. A script that renames internal files does not need the same controls as a workflow that updates customer contracts. We scale the safeguards to the real risk instead of treating every automation as either harmless or mission-critical.

Absolutely. Our packages are reference points, not cages. Custom work is the core of what we do. If your business needs a specific approval flow, unusual document generator, device connection, RFID/NFC workflow, custom reporting logic, internal portal, role system or integration that does not fit a standard package, we scope it around the requirement.

The process is straightforward: we clarify the desired outcome, identify dependencies, estimate the work and add it as a clearly priced module or separate phase. We do not hide custom requirements inside vague promises. That makes it easier for you to decide whether the feature is commercially worth building before money is committed.

We price based on scope, complexity, risk and the amount of specialist work required — not simply on the number of pages or screens. A website with five pages and complex multilingual forms can require more work than a ten-page informational site. A short automation that touches financial data may need more testing and safeguards than a longer internal utility script.

For clearly defined work we prefer fixed project pricing or a defined starting price with assumptions written down. For discovery-heavy or evolving enterprise work, milestones or phased budgets are usually more responsible. Our pricing page gives realistic starting points so you can judge whether we are in the right range before investing time in a detailed conversation.

For project work, we normally structure payment around the size and risk of the engagement. Smaller projects may use an initial deposit and a final payment. Larger applications are better divided into milestones so payment follows meaningful delivery stages rather than one large invoice at the beginning or end.

The exact schedule is stated in the proposal before work begins. This protects your cash flow and gives us a clear commercial framework for reserving development time. Recurring hosting, maintenance or support plans are billed on the agreed recurring cycle. There should be no surprise invoice for work that was never approved.

The useful comparison is not “€2,000 versus doing nothing.” It is €2,000 versus the ongoing cost of the manual process. Imagine a workflow that takes one employee four hours every week. At a fully loaded internal cost of €30 per hour, that is roughly €6,000 per year before counting mistakes, interruptions, delays or the management time required to check the work. If two people touch the process, the cost rises quickly.

If a reliable automation removes most of that work, a €2,000 investment can pay for itself within months and continue producing value afterwards. We do not claim every script has dramatic ROI, which is why we ask about frequency and time saved before recommending automation. The best projects are the ones where the economics make sense without needing optimistic assumptions.

Changes happen. The important part is making them visible. If new information reveals that the original solution needs a different workflow or an extra integration, we first explain the impact. You receive a clear change proposal or revised milestone before additional billable work is added.

We distinguish between normal implementation clarification and genuine scope expansion. Correcting a detail that was already part of the agreed feature is not the same as adding a new user role, payment provider, mobile application or reporting module. Keeping that distinction clear prevents conflict and gives you control over budget throughout the project.

Yes. Launch is not the point where software stops changing. Browsers update, third-party APIs evolve, security patches become available, content changes, traffic grows and users discover improvements that were impossible to predict before real usage. We offer monthly care and managed application plans for clients who want us to remain responsible for the technical health of the product.

Depending on the plan, this can include updates, monitoring, backups, security checks, minor content or configuration changes, performance reviews and technical support. Larger applications may require a tailored maintenance agreement because the operational risk and infrastructure are different from a standard website.

For suitable websites and applications, we can host on infrastructure at All-Inkl and manage the deployment as part of a maintenance plan. That gives us a practical environment for domains, SSL/TLS, PHP applications, databases, email-related configuration and regular website operations without forcing the client to manage the server layer personally.

Hosting is not one-size-fits-all. A brochure website, an online shop and a real-time application with heavy background processing have different requirements. If the project outgrows the current hosting profile, we will recommend optimisation, a more suitable package or a different infrastructure architecture rather than pretending one server setup fits every future workload.

We first measure where the bottleneck is instead of guessing. Performance problems can come from oversized media, inefficient frontend code, slow database queries, third-party scripts, missing cache layers, background jobs or simply infrastructure that no longer matches the workload.

Optimisation may involve image and asset compression, query tuning, caching, CDN strategy, lazy loading, code splitting, database indexing or infrastructure changes. If higher traffic is a planned business event — for example a campaign, product launch or seasonal peak — tell us in advance. Capacity planning before the spike is always cheaper than emergency work after customers are already seeing timeouts.

They can be, depending on the selected care plan. For managed projects we define what is backed up, how often, how long backups are retained, which software components are updated and which checks are performed. A useful backup strategy also considers recovery: a backup that has never been tested or cannot be restored quickly is not much of a safety net.

Security maintenance can include dependency updates, access review, configuration checks and monitoring relevant to the stack. No provider can honestly promise that a connected system will never have a vulnerability, so the professional approach is reducing attack surface, keeping software current, limiting access and having a clear response path when something needs attention.

We build with data minimisation, appropriate access control and secure transport in mind. That means collecting only data the workflow actually needs, separating permissions by role where appropriate, protecting credentials, using encrypted connections, avoiding unnecessary third-party exposure and designing retention or deletion behaviour when the project requires it.

GDPR compliance is broader than source code. The company operating the system still needs the correct legal basis, privacy information, contracts with processors where required, retention policies and internal procedures. We can build the technical system to support those obligations and document relevant data flows, but legal compliance should be reviewed in the context of your organisation and, where necessary, with qualified legal or data-protection counsel.

Secrets should not live in public JavaScript, Git repositories or random text files passed around a team. For production systems we keep credentials outside publicly served code, use environment-level configuration or appropriate secret storage, restrict permissions to what the integration needs and avoid sharing master credentials when a scoped account or token is available.

We also recommend separating development/test credentials from production credentials. If a third-party service supports token rotation, limited scopes or separate service accounts, we use those controls where appropriate. Good credential hygiene is one of the simplest ways to reduce the impact of a mistake or compromised account.

Ownership and licensing are stated in the project agreement so there is no ambiguity later. For normal custom client work, the objective is that you can operate the solution you paid for and retain control over your business data. Third-party libraries, fonts, APIs, SaaS services and open-source components can have their own licences, which remain subject to their respective terms.

We do not want technical lock-in to be the reason a client stays with us. We want clients to stay because continued collaboration is useful. For larger systems we can also define handover documentation, deployment information and operational responsibilities so the project can be maintained responsibly over time.