Eight services. Four categories. Two registered activities.

Typical clients are small and medium-sized businesses in the United Kingdom and Europe, professional service providers, entrepreneurs, growing operational teams, and organisations replacing manual processes or modernising older applications. Selected consumer-facing software projects are also undertaken where the use case is well defined.

There is no minimum company size. What matters more is that somebody on the client side can describe how the work is done today and can make decisions about how it should be done in future.

Software development — registered activity 62012 — means designing and building working software: platforms, applications, internal tools, automations and connected systems. The output is software that people use.

IT consultancy — registered activity 62020 — means analysing requirements, evaluating technical options, planning improvements, reviewing systems and advising on delivery. The output is documented analysis, structured recommendations and clearer decisions.

The two are separated deliberately. Advice that exists only to justify a build is not advice, so consultancy engagements can conclude with a recommendation not to build anything.

Yes, and it frequently is. A feasibility or architecture engagement can be booked entirely on its own, with no obligation to continue into a build and no requirement to use DEVNOVA for any resulting development.

Where a client does choose to continue, the analysis already completed becomes the starting point for the development proposal rather than being repeated as billable discovery.

Price follows confirmed scope. The main factors are the number and complexity of features, the number of user roles, integrations with third-party services, data migration from existing systems, the depth of testing required, documentation, and the timescale.

After an initial discussion, a written quotation sets out the deliverables and the price. Payment timing and project-specific conditions are defined in the accepted quotation, statement of work or written agreement rather than by a single universal schedule.

No. Every price shown on this website is an indicative starting point that illustrates where a service typically begins for a straightforward scope. It is not a quotation and does not constitute an offer.

A project with several integrations, complex permissions or migration of existing data will sit above the starting point. The written proposal is the only document that sets a price for a specific piece of work.

Often, yes — but only after a review. The review looks at how the application is built, how it is hosted, what access is available, and how much of the original knowledge still exists inside the organisation.

Some applications can be improved incrementally at modest cost. Others carry enough technical debt that staged replacement is more sensible than continued patching. The review says which, with reasons, before any development work is proposed.

Integration is possible where a third-party service provides a documented interface and its terms permit the intended use. Universal compatibility cannot be promised, and it would be dishonest to imply otherwise.

Before a project is confirmed, the following are assessed: third-party compatibility, access permissions, API limitations such as rate limits and available fields, licence costs, and provider terms. If an integration is not viable, an alternative approach is proposed instead.

Maintenance and support can be arranged, and are described separately from the build price. They are not automatically included in a project.

Arrangements vary: some clients prefer a small monthly allowance for changes, others prefer to request work as needed, and some take the code and maintain it internally. Handover documentation is written so the third option is realistic rather than theoretical.

Yes. Work is carried out remotely, and organisations elsewhere in Europe are welcome to enquire. Communication is in English and prices are quoted in euros.

Applicable taxes, invoicing requirements and any location-specific considerations are confirmed in the written proposal. Where a project has regulatory implications, clients are advised to take their own professional advice — that is not a service DEVNOVA provides.

Enough to hold a useful first conversation: a description of the process or product, the problem being solved, the systems or tools already in use, any integrations expected, an approximate budget range and a preferred timescale.

Nothing needs to be finalised. Approximate answers are genuinely fine — several fields on the enquiry form exist precisely so that "to be discussed" is a valid response.

Requirements change during projects; that is normal rather than a failure. What matters is that changes are visible.

A change to agreed scope is documented as a written change request describing the work, its effect on the timescale and any additional cost. Work on it begins once it has been accepted in writing, so no unexpected charge appears at the end of a project.

By telephone on +44 7853 151 992 or by email to support@devnovasolutions.tech, as early as reasonably possible, with written confirmation of the request.

Completed work and approved project stages remain payable, and third-party costs already incurred — such as non-refundable licences or external services — may also remain payable. Cancellation does not automatically create a right to a full refund, and statutory rights are not excluded. Full details are in the Cancellation Policy.