Choose between AFAS and custom software one process at a time. First investigate whether the available AFAS features and configuration can support the work properly. A separate application may fit where an important part remains unsupported, but it also introduces development, integrations and maintenance. Our custom software guide covers the wider decision; the cost guide helps you request a proposal.
What are you comparing: AFAS, configuration or custom software?
AFAS supplies business software. Its ERP product page describes functions including finance, HR, customer records, projects and workflows. The package offers more than a fixed accounting system. Investigate possible configuration before treating a missing workflow as a product limitation.
These three routes don’t automatically solve the same problem. If you compare an AFAS implementation with a customer portal proposal, the second option may still need an administration package. A lower price means little when the scope differs.
Write down the work the solution must support. Who enters information, who approves it and what data is needed afterwards? Use a recent difficult situation rather than relying only on a feature list.
When should you investigate the existing AFAS configuration first?
Start with how you use AFAS now. A missing overview may be a reporting requirement. Duplicate entry could result from a working arrangement or an integration that hasn’t been configured. That needs a different solution from a process whose required data and actions aren’t available.
Ask an AFAS specialist to work through a concrete situation. An employee might submit expenses, a project manager dispute one item and the accounts team process the revised amount. Can the team complete the process, including the exception? Record where it breaks down and what change is proposed.
Distinguish three outcomes: it already works, it needs configuration, or a demonstrated gap remains. Ask about maintenance and training for configuration too. A feature nobody understands contributes little to everyday work.
Having a distinctive customer process doesn’t prove you need custom software either. First identify which parts really differ. Perhaps an internal habit can change without disadvantaging the customer. Hold on to the outcome you need, rather than automatically preserving every existing click.
When might a separate custom application fit?
Custom development is worth investigating when that assessment shows the required workflow cannot be supported adequately. It could involve a calculation, a user interface for a particular audience or a process needing data from several systems. Describe the missing capability precisely.
Suppose a service business wants customers to assemble requests whose conditions vary by contract. This is a hypothetical example. The investigation should establish whether those rules can be configured in the existing solution. Only if that doesn’t fit should you compare an additional application with other routes.
A dedicated application can have screens and rules designed around the brief. It also creates responsibility for future changes. Somebody must handle a new contract type, a changed integration or a security update. “We’ll have it built once” isn’t a maintenance plan.
For a customer-facing environment, use the questions in our article on customer portals. Request a demonstration from the user’s perspective: not merely whether a form exists, but whether someone can follow a request and correct an error.
How do you compare the three routes fairly?
Compare the options against the same task and exceptions. The table provides assessment questions, not a general ranking.
| Choice | What should you investigate? | What responsibility remains? |
|---|---|---|
| Improve the AFAS configuration | Can available features and configuration support the process? | Internal process management, data quality and user instruction |
| Connect AFAS to a separate application | Which work stays in AFAS and which moves outside it? | Both components and their data exchange |
| Replace a process completely | Which functions need to be delivered again? | Development, migration, maintenance and connection to the rest of the business |
A combined approach isn’t automatically the ideal compromise. If almost every action requires changes in two systems, the extra complexity may weigh heavily. Conversely, a small addition may let you retain administration that already works well. The process should determine the boundary between the systems.
What should an AFAS integration demonstrate?
AFAS documents GetConnectors for reading and UpdateConnectors for changes. An AppConnector determines which connectors a token may use. This enables data exchange, but doesn’t prove that every desired action is available.
Have the required fields and changes demonstrated before budgeting for the separate application. In the request example, you need to know how an approved request is recorded, which reference is returned and how corrections work. A general statement that “there’s an API” doesn’t answer those questions.
Agree which system is authoritative for each piece of information. Can staff change a customer address in both places? What happens if a message fails to arrive or is submitted twice? These are integration design questions, not faults you can attribute to AFAS without investigating.
Ask to see a failed transaction too. The team must be able to recognise an error, correct it and retry without creating a duplicate record. Include this in acceptance checks; a demonstration covering only the ideal path isn’t enough.
How do you compare costs without inventing a break-even point?
The AFAS pricing page says pricing depends on company-specific factors and that employee numbers play a role in its licensing model. Request a proposal for your situation. The product line and additional services matter; a price for a different offering isn’t a sound budget for your ERP implementation.
Request a defined scope for custom development too, with maintenance and expected changes listed separately. There isn’t a universal year when custom software becomes cheaper. The outcome depends on scope, usage, maintenance and how much manual work actually disappears.
Choose one comparison period and include the same categories for every route:
| Cost category | What belongs in the comparison? |
|---|---|
| Starting | Analysis, configuration or development, migration and testing |
| Usage | Subscriptions, hosting and any usage-dependent charges |
| Connections | Existing and new integrations, including maintenance |
| People | Training, internal administration and remaining checks |
| Change | Alterations to processes, interfaces and data |
| Leaving | Export, handover and potential replacement |
Keep expected savings visible as assumptions until measured. If a proposal relies on reduced administration time, check whether those hours genuinely disappear or become other work. Compare what happens when the business grows and when usage falls too.
Does owning the code remove every dependency?
For custom development at TopDevs, the agreement is that the code belongs to you and stays yours. That helps in practice only if another supplier can continue the work. Consider documentation, access, build instructions and arrangements for the services involved.
Dependencies remain, including cloud platforms, external components and the people maintaining the system. A separate application may still need AFAS for administration. Discuss data and services as well as code. Our explanation of code ownership and vendor lock-in examines this further.
How do you assess a proposal before deciding?
Ask every supplier to perform the same scenario. Include an ordinary request, a correction and a failed transfer. Specify who may see each part. This assesses the work rather than a supplier’s presentation skills.
For each missing component, request a clear answer: is it included, does it require additional work, or isn’t it supported? Record assumptions about data availability and cooperation from other suppliers. You can then see where an attractive price still contains uncertainty.
Agree an acceptance point before moving the entire process. A limited trial may be enough to test an important assumption. The aim isn’t to collect another product alongside the first, but to make a reasoned decision about how the work will operate.
How do you actually get started?
Describe the process causing problems and first ask what the current AFAS configuration can solve. If a demonstrated requirement remains, compare configuration, integration and custom development against the same scope and cost categories.
TopDevs can help investigate custom software development. We may also conclude that configuring the existing package more effectively is enough. Book a call and bring your process example.
