Approach

From your workflow to a project you own.

We start with a work situation, try the workflow with your team, then build the agreed scope. Stages and deliverables are defined before setup.

A paid custom project, with source code and documentation handed over to your team.

Describe my workflowSee a follow-up example

01

Define the need

We choose a process and identify the people using it. Important exceptions, tools to keep and validation criteria belong in the discussion from the start.

At this stageA scope to approve, responsibilities and criteria for assessing the delivered work.

Who does what?
Nordis’s role
Ask questions, describe the workflow and propose a scope with explicit exclusions.
Your role
Explain the actual work, name the person who can make decisions and confirm priorities.

02

Try the workflow

A mockup or prototype helps check the screens and sequence before building the whole system. We distinguish what is shown from what already works.

At this stageA reviewed workflow and decisions to incorporate into the build scope.

Who does what?
Nordis’s role
Represent the selected workflow and identify the simulated parts.
Your role
Walk through common situations and flag anything missing or inconsistent with the work.

03

Build the system

The selected functions take shape according to approved decisions. A need discovered along the way is reviewed before it becomes additional work.

At this stageA version ready for review, with the status of its functions and any open items.

Who does what?
Nordis’s role
Develop the agreed functions and identify decisions or dependencies that need resolving.
Your role
Provide the authorized materials needed for the project and answer questions about how the work operates.

04

Validate concrete cases

We check expected workflows and selected exceptions using suitable test data. Gaps are assessed against the scope rather than automatically treated as new requests.

At this stageA validation summary and a decision on the conditions needed for setup.

Who does what?
Nordis’s role
Prepare the agreed checks, document gaps and address those covered by the planned work.
Your role
Check business scenarios, confirm expected results and approve or report discrepancies.

05

Set up and hand over the project

You own the entire custom project. We prepare takeover and deployment in the agreed environment. Data migration and team onboarding are defined during scoping.

At this stageA project you can take over, host elsewhere and develop further with another team, without mandatory dependency on Nordis. Identified outside dependencies retain their licences and terms.

Who does what?
Nordis’s role
Hand over the source code specific to the project, custom configurations, documentation and deployment instructions. Transfer access through the project’s authenticated mechanisms.
Your role
Confirm the people responsible and take control of data and access. No credentials go through the public brief.

06

Make changes as needed

After handover, a new rule, connection or screen may become necessary. We describe the change and its effects before agreeing on the work.

At this stageA defined change billed under the agreement, without assuming unlimited improvements or support.

Who does what?
Nordis’s role
Assess the request and propose a separate scope for the change.
Your role
Prioritize the need and accept the terms before work on the change begins.

Project handover

You own the entire custom project.

Construction and setup are a defined, paid initial project. You receive the source code, project-specific configurations, documentation and deployment instructions.

You can change teams or hosting providers without mandatory dependency on Nordis. Hosting, support and future changes still need to be planned; outside services retain their terms and fees.

Rights, outside services and costs

You receive the source code specific to the project, custom configurations, documentation and deployment instructions. You control your data and access. Access is handed over through the project’s authenticated mechanisms, never through the public brief.

You can take over the project, host it elsewhere and have another team develop it further. There is no mandatory dependency on Nordis or hidden Nordis usage royalty. Your custom project is not published without your agreement.

Construction and setup are a defined, paid project. After delivery, you don’t pay a Nordis subscription to use your instrument. Hosting remains a cost. Support and changes are separate work, with stated terms and costs.

Open source dependencies retain their licences; outside services retain their terms and fees. We identify them before the project. These licences do not hold back your specific code: they avoid pretending to transfer ownership of a public framework or an outside account without respecting its terms.

Examine subscriptions before replacing them.

We review what is used, what overlaps and what needs to stay. A custom project also needs to be assessed against its build, hosting and maintenance costs.

How to compare costs

Possible gross savings are the subscriptions actually removed over a time horizon chosen with you. To assess net savings and the break-even point, we also count the paid initial build and migration, then hosting, retained services, maintenance and relevant changes over that same horizon.

No project price, hosting cost or payback period is assumed here. A custom tool cannot replace all software and is not cost-effective in every situation. Scoping also helps recognize when keeping an existing tool is the better choice.