When you need a report changed, an integration fixed or manual work automated, the priority is a clear result. Working directly with a developer puts you in touch with the person who will build the solution.

NAV / BC services: two delivery models

ERP services organisation

  1. Client
  2. Account Manager
  3. Project Manager
  4. Business Consultant
  5. Team Lead
  6. Developer

Direct collaboration

Client

Independent NAV / BC Developer

Requirements · Analysis · Technical advice · Design · Development · Testing · Ownership of the agreed result

Communication
ERP services organisation: 5 handovers via 4 intermediaries
Direct collaboration: 1 direct relationship
Administrative overhead
ERP services organisation: Management and administration costs
Direct collaboration: Fewer intermediaries, less overhead
Technical decisions
ERP services organisation: Coordinated across several roles
Direct collaboration: Directly with the developer
Accountability
ERP services organisation: Shared across several roles
Direct collaboration: The developer owns the agreed result

Are you paying for a technical solution—or the whole organisation?

When you commission a NAV or Business Central change, the price can cover more than development time. Sales, project management, consulting and administration can all contribute to the cost of delivery. Before choosing a provider, ask how much of that structure your particular task needs.

In a large ERP services organisation, the route to the developer may look like this: client → account manager → project manager → business consultant → team lead → developer. The developer may sit at the lowest organisational level in that hierarchy, even though they do the technical work and build the solution you are buying.

Each additional role has a cost. Planning, internal meetings, reporting and handovers can influence service pricing.

Fewer handovers. A clearer conversation.

Suppose orders imported into Business Central are being duplicated. You need the system to recognise an order it has already received and avoid creating it again. The developer needs to understand how orders are identified, why they are resent and what staff should see when this happens.

When questions and answers pass through several people, context can be repeated or another round of clarification may be needed. With direct access to the developer, you show the example to the person who will investigate the integration. They can ask for the missing details, explain the options and agree how the change should work.

A shorter communication path can make technical decisions faster. Less effort goes into relaying information, leaving more time to understand and solve the problem.

One person from the first conversation to the working change

When you work with me, the same person listens to your requirements, investigates the problem, provides technical advice, designs the solution, writes the code and tests it. I also take responsibility for the agreed technical outcome.

Before starting, we agree what needs to change, how the system should behave and how we will check the result. If your version or existing customisations limit the options, I explain that before we agree the work. You can ask directly why I recommend a particular approach and what it means for your staff.

This keeps the context of the task together. Your examples and business rules reach the person implementing them directly, with fewer opportunities for the requirement to be interpreted differently along the way.

Lower overhead and more transparent pricing

An independent developer does not need to maintain the same management and administrative structure as a large services organisation. Fewer intermediaries and less internal coordination can reduce overhead and support more competitive pricing for technical work.

A proposal should explain what is included: investigation, development, testing, deployment and ongoing support. Depending on the task, we can discuss a fixed scope, time-based work or delivery in stages. Additional work and its cost are agreed before it is carried out.

A lower price or faster delivery is not automatic: scope, the condition of the existing system and developer availability all matter. Direct collaboration does, however, make it easier to connect the proposal to the work you actually need.

Clear responsibility for the technical result

When you discuss the solution with the person building it, you know who to contact about a technical question or a defect. I can explain what changed, how it works and which examples were used to test it.

We agree the scope, acceptance criteria, code and documentation handover, and support arrangements in advance. Changes are tested in a suitable test environment before production deployment is agreed with you. That gives you a concrete result to assess alongside the time spent delivering it.

Which tasks suit direct collaboration?

This model is especially useful when you already use NAV or Business Central and need a specific improvement: an AL extension, a C/AL modification, a report or document layout change, an import fix, a REST API integration or troubleshooting.

I can also help automate repetitive work, build data imports and exports, and extend existing functionality. An engagement can start with one problem, with further improvements planned around your priorities.

For larger projects, I can contribute as a developer alongside your team or other specialists.

More than 12 years of NAV and Business Central development

I am Evaldas Jablonskas, a Microsoft Dynamics NAV (Navision) and Dynamics 365 Business Central developer with more than 12 years of programming experience in these systems.

My work covers AL and C/AL development, NAV and Business Central modifications, Microsoft SQL Server, REST API integrations, data imports and exports, and business process automation. Experience with older NAV versions and newer Business Central solutions helps me assess how a change will fit the system you already use.

I want to understand both the technical requirement and the difference it should make to your staff. BC Invoice Portal, a solution I built independently, is a practical example of that approach.

BC Invoice Portal: from an idea to an independent solution

BC Invoice Portal is a web-based invoicing solution I developed independently. Employees sign in to the portal rather than the Business Central user interface. The portal administrator manages their staff accounts.

The portal retrieves customers and items from Business Central. Staff can create sales invoices, submit them for calculation and initiate posting in Business Central directly from the portal. Business Central calculates prices, totals and VAT.

The integration uses REST APIs, Microsoft Entra ID and OAuth 2.0, with the necessary application permissions configured for access. The solution shows how one developer can connect a staff workflow, a web interface and ERP functionality into a working product.

Explore BC Invoice Portal →

Start with the task you need to solve

Briefly describe what is not working or what you want to improve. Include your NAV or Business Central version, an example and the result you need. Mention any deadline you are working towards.

We will discuss the possible approach, scope and next steps. You will be speaking directly with the developer who will carry out the work.