Questions worth answering before a software engagement begins.

There is no responsible universal figure. Cost depends on business logic, users and permissions, integrations, data migration, payments, mobile requirements, security, delivery risk and the level of responsibility expected after launch. A credible price starts with a credible scope.

Yes. A smaller release should narrow the scope without removing the part that proves the product is useful. A good first version is deliberately focused; it is not simply the full product with the difficult parts left out.

Ownership, repository access, infrastructure, production credentials, company data and third-party accounts should be explicit in the agreement. Technical control is an operating arrangement, not a sentence added to the end of a contract.

Yes, subject to technical assessment. We review the architecture, codebase, dependencies, data, deployment process, integrations, security controls, backups and known production behaviour before recommending whether to stabilise, evolve or replace.

No. Rebuilding can remove structural constraints, but it can also discard years of business knowledge embedded in the current system and introduce unnecessary transition risk. We recommend the option with the stronger technical and commercial case.

We combine preventative testing with disciplined diagnosis: reproduce the issue, identify the affected release and impact, fix the underlying cause, verify the relevant behaviour and restore service where necessary.

We can engineer systems with data protection, access control, retention and traceability in mind. Full compliance, however, also depends on the organisation's processing purposes, contracts, policies, data categories and legal responsibilities.

Nördia is a software engineering company. Security is part of how we design and operate software, but specialist assurance such as independent penetration testing can be commissioned separately where the risk profile calls for it.

Yes, where it improves speed or capability without weakening control. AI does not remove the need for clear architecture, permissions, data boundaries, verification or human accountability for high-impact actions.

We begin with the architecture and the consequences of failure. Identity, permissions, sensitive data, public exposure, administrative capability, third-party dependencies, secrets, deployment and recovery are considered according to the product rather than through one universal template.

Where independent penetration testing or specialist assessment is justified, it can be coordinated separately. External testing is most useful when the delivery team has already established clear boundaries, test accounts, evidence and responsibility for remediation.

Yes, where the engagement requires independent assurance. Scope normally needs to define the application, environments, authentication roles, excluded systems, data constraints and whether source-assisted review is expected. A third-party tester does not automatically require unrestricted access to the entire codebase; the appropriate level of access depends on the assessment.

Findings should enter the engineering workflow with severity, the affected area, reproduction evidence, remediation and retest status. The point of independent testing is to improve the system, not to buy a certificate-shaped document.

Lock-in has several forms. A product can depend on a cloud provider, a proprietary API, undocumented supplier knowledge, a private account, one developer or a data model that cannot be exported safely. Avoiding every dependency is neither realistic nor automatically desirable.

We identify dependencies that materially affect control and make them deliberate. Repository ownership, infrastructure access, credentials, data export, deployment knowledge and architectural boundaries can reduce avoidable dependence even when the product intentionally uses managed third-party services.

When the product benefits from them. A distributed architecture introduces network failure, deployment coordination, monitoring requirements and data-consistency trade-offs, so splitting a system into services is not a badge of maturity.

The simplest architecture that gives the product the boundaries it genuinely needs is usually the stronger starting point. A distributed system becomes appropriate when independent scaling, security, ownership or operational requirements justify the additional cost.

We assume external systems can be slow, unavailable or inconsistent. Depending on the workflow, integration design may include validation, timeout rules, duplicate-event handling, retries, durable state, correlation identifiers and reconciliation.

The important part is that failure is visible and recoverable. A customer order or payment should not disappear between two platforms simply because the API call worked during development.

Migration is treated as a controlled product change, not a one-off import script. We first understand source quality, identifiers, duplicates, historical rules, relationships and which system will become authoritative after the transition.

For important migrations, we favour repeatable conversion, validation totals, exception reporting, rehearsal and a clear cut-over or coexistence plan. Migration is complete when the business can trust the new data, not when the script exits successfully.

The exact scope is contractual, but it can include monitoring, backup verification, recovery planning, dependency maintenance, release management, incident handling, performance work and continued engineering. The useful scope depends on how critical the product is to the business and what internal capability already exists.

We separate operational responsibility from vague promises of permanent availability. Responsibilities, response expectations, access, exclusions and escalation should be clear enough that both sides know what happens when the product is under pressure.

Yes. The useful boundary can be architecture, a difficult subsystem, delivery infrastructure, security-sensitive capability, integration work or a defined product stream. We do not need to own the entire codebase to contribute effectively.

Responsibility needs to be clear. Shared repositories, review rules, release authority, coding standards and operational ownership should be agreed so two teams do not create two competing systems inside the same product.

We look for repeated work with stable inputs, identifiable rules and a meaningful cost in staff time or errors. A process that changes every week or depends on nuanced human judgement may need better workflow support before it needs automation.

When AI is involved, we distinguish assistance from authority. Classification, summarisation and recommendation can reduce manual work, while high-impact changes remain behind deterministic controls or human review when the risk requires it.