<p>A software demonstration shows what a platform can do. Your implementation has to show what it can do with your records, exceptions and existing systems.</p><h2>Give both options the same examples</h2><p>Prepare a short evaluation pack: a normal order, an amended order, a partial delivery and a record with missing information. Choose cases from your own operation and remove sensitive data as needed.</p><p>Ask each supplier to walk through them. Record the difference between the following answers:</p><ul><li><strong>Available as standard:</strong> Does the demonstrated behavior match your rule?</li><li><strong>Configurable:</strong> Who configures it, and is that work included?</li><li><strong>Requires development:</strong> Who maintains the extension when the platform changes?</li><li><strong>Unsupported:</strong> Can the business accept a different process?</li></ul><h2>Compare the implementation work</h2><p>Both options need data preparation, migration, testing, training and support. Include the systems that stay, the integrations they require and the way a failed update will be investigated. A license price and a custom development quote rarely describe the same boundary.</p><p>For <a href="/case-studies/marketing-agency-erp-development">ZMatic</a>, interconnected spreadsheets contained rules that had to become ERP behavior. That is a reason to investigate fit carefully; it does not establish that every spreadsheet-based operation needs a custom system.</p><h2>Look at ownership after launch</h2><p>Ask who can change the system, export the data and support the integrations. Include recurring fees and the changes you already expect, such as a new approval rule or business unit. Record the contractual limits that affect a future move.</p><p>A packaged platform may fit. A custom system or a combination may fit better. The recommendation should explain that choice using your examples. <a href="/custom-erp-development">Explore our ERP approach</a>.</p>

Custom ERP or an off-the-shelf platform?

<p>A workbook can be a database, a process manual and a set of business rules at the same time. Replacing it with software starts by separating those jobs.</p><h2>Find the rules, including the overrides</h2><p>Follow an actual order or report through the files. Identify who enters the information, which formulas affect a decision and where the result is copied next. Ask about hidden columns and manual corrections. An override may represent an exception the business still needs.</p><p>In <a href="/case-studies/marketing-agency-erp-development">ZMatic’s ERP project</a>, understanding the dependencies between spreadsheets informed the data model and migration. The replacement connected customer history, orders, reporting and client self-service.</p><h2>Do not turn every tab into a screen</h2><p>Decide what the record represents and which system owns it. An illustrative example: after an approved order changes to a partial delivery, the application needs rules for the remaining quantity, status, documents and information sent to finance. Storing the rows does not define that behavior.</p><p>Write the exceptions into the requirements with the roles allowed to handle them. The people using the workbook can confirm whether the proposed behavior preserves the rule or deliberately changes it.</p><h2>Move the data and the responsibility</h2><p>Keep the original files. Map identifiers, choose which history to move and list incomplete or conflicting entries. Assign someone to resolve them rather than filling gaps with guessed values.</p><p>Rehearse the import and check totals, relationships and complete tasks. Agree when the new system takes over and how problems will be reported. If both remain in use, specify which one owns each record.</p><p>That is the starting point for <a href="/custom-erp-development">custom ERP discovery</a>: understand the business inside the files before designing their replacement.</p>

When spreadsheets become an operating system

<p>A count of screens can describe the interface. It will not tell you how much history must move, which integrations must keep working or how the business will switch to the new version.</p><h2>Ask for work you can examine</h2><p>An estimate should distinguish investigation, design, implementation, integrations, migration, testing and rollout. Under each area, ask what is known, what is assumed and what still needs access or a technical check.</p><p>A range should explain its uncertainty. If an undocumented API is responsible for a large part of that range, ask which investigation would narrow it. A fixed price needs a defined scope and a clear agreement about changes.</p><h2>Include the transition</h2><p>Discuss data cleanup, migration rehearsals, reconciliation, training, temporary operation and rollback. Give those activities an owner. Moving a database and moving a business to the new system are related work, but they are not the same task.</p><p><a href="/case-studies/merp-prep-software-modernization">MERP/PREP</a> combined a web, mobile and backend rewrite with DevOps and migration. The delivery team reports a cutover without service interruption and 90% lower AWS costs afterwards. Those project outcomes illustrate the scope; they are not a price or savings forecast for another platform.</p><h2>Clarify the cost after release</h2><p>Separate hosting and third-party services from maintenance, support coverage and continuing product development. Ask what the engagement includes and what needs a separate arrangement.</p><p>We do not publish a universal modernization price because the existing software and transition requirements differ. <a href="/pricing">Our pricing approach</a> explains how we establish the scope, and <a href="/digital-transformation">our modernization work</a> covers the change around the code.</p>

What actually shapes a modernization estimate?

<p>A product strategy should help a team say yes to one thing and defer another. A list of everything the software could do does not make that choice.</p><h2>Put the user and decision in the same sentence</h2><p>“Add a dashboard” does not say why it is needed. As an illustrative requirement, “let operations see which bookings need intervention before the next shift” identifies a user, a decision and a moment when the information matters.</p><p>Bring examples of the current work. Where does somebody wait, repeat an entry or ask another person for context? Check that the observation represents a recurring problem before expanding it into a roadmap.</p><h2>Make the trade-off explicit</h2><p>Choose a first scope that completes a task. List the dependencies and the capabilities left for later. For each proposed feature, record the problem it addresses and what evidence supports its priority.</p><p>Keep a short decision log. If new evidence changes the plan, the team should be able to see what changed and why, rather than reopening the same argument from memory.</p><h2>Choose the next evidence, not just the next feature</h2><p>An undocumented integration may need a technical check. A confusing interaction may need a prototype. Customer adoption needs evidence from customers and use. These are different uncertainties and should not be bundled into one promise that development will resolve them all.</p><p>Agree who owns the next decision and when to review it. <a href="/five-day-strategy">Our strategy work</a> defines that direction; <a href="/discovery">discovery</a> develops the detail needed to deliver it.</p>

A product strategy starts with a decision

<p>A rewrite can reproduce the obvious screens and still lose a rule the business depends on. Those rules may live in code, an export, an old spreadsheet or the knowledge of the person who handles exceptions.</p><h2>Build a baseline of behavior</h2><p>Record the important tasks, their inputs and expected results before changing the implementation. Include calculations, permissions, reports and integration messages. Ask what happens after a correction or an incomplete record, not only on the normal path.</p><p>In <a href="/case-studies/marketing-agency-erp-development">ZMatic’s move to a custom ERP</a>, the spreadsheet dependencies were part of the business knowledge that needed to be understood. The migration was more than a transfer of rows.</p><h2>Give each dependency a test</h2><p>Identify the systems and people consuming the current output. For a document workflow, that may include existing identity and permission rules: <a href="/case-studies/document-management-system%E2%80%93dms">ECONT’s DMS</a> retained sign-on and access supplied by the ERP.</p><p>Use those dependencies to define acceptance examples. A new screen may look right while a report or downstream system receives the wrong value.</p><h2>Rehearse the move</h2><p>Map identifiers, decide which history moves and keep unresolved records visible. Rehearse with representative data. Compare business totals and relationships as well as counts, then test complete tasks with the imported records.</p><p>Before release, agree which system becomes authoritative, who performs the checks and what would trigger a rollback. If both systems remain active temporarily, write down who owns each record during that period.</p><p>The <a href="/digital-transformation">modernization scope</a> needs to include this transition work alongside the replacement code.</p>

How to modernize software without losing the business rules

<p>An end-to-end team can take responsibility for design, engineering and release. It still needs decisions that only the founding team can make: which customers matter first, what they need and what evidence justifies the investment.</p><h2>Give the team a task to deliver</h2><p>Describe who will use the first release and what they must be able to finish. “A platform with a dashboard” is open-ended. A task with a beginning, an outcome and known dependencies can be scoped and tested.</p><p>Bring customer conversations, existing material and examples of the current workaround. Separate what you have observed from what you hope users will do.</p><h2>Keep the first release complete</h2><p>A smaller scope can serve fewer users or fewer use cases. It should still account for access, failed actions, external dependencies and support. Half a transaction can be a smaller build without being a useful product.</p><p>Name what is deliberately excluded. This protects the release from becoming a collection of every idea raised during design.</p><h2>Make reviews about decisions</h2><p>Review prototypes and working software against the agreed task. The delivery team tests the implementation; your team checks whether the behavior fits the intended operation. Neither activity alone proves demand.</p><p>After launch, connect feedback to a choice: correct a defect, change the flow, add a capability or reconsider the proposition. Agree who can make that choice and how it affects the scope.</p><p><a href="/end-to-end-development">See how we divide delivery responsibilities</a>, or start with <a href="/mvp">the question your first release needs to answer</a>.</p>

What an end-to-end team needs from a startup

<p>If an order is entered once in sales and again in operations, the first question is where the information stops travelling. Buying a new platform before answering that can leave the same handoff in a different interface.</p><h2>Follow one record across the business</h2><p>Choose an actual order, booking or document. Track who creates it, what changes, which systems receive it and who checks the result. Include the spreadsheet or email used when the main application does not have the answer.</p><p>Look for the rule behind the extra step. Someone may be checking a total because identifiers do not match, or copying a record because the receiving system needs a different representation.</p><h2>Decide who owns the information</h2><p>For each record, name the authoritative system and the fields other systems can change. Agree how to recognize a repeated message and who resolves an incomplete or failed update.</p><p>Our <a href="/case-studies/cupffee-ecommerce-crm-integrations">Cupffee integration work</a> involved Zoho product mapping and carrier calculations. Our <a href="/case-studies/document-management-system%E2%80%93dms">ECONT DMS</a> used ERP permissions and existing sign-on. Both involve connected systems, but their ownership and access questions differ.</p><h2>Give the first change a clear boundary</h2><p>Select a workflow that can be completed and checked. Include data preparation, permissions, tests, training and support in that scope. Define the starting measure for the problem you intend to improve, then review the result after release.</p><p>That gives a broad transformation programme an initial decision the business can examine. <a href="/core-business-solutions">Our business systems work</a> starts with those records and handoffs.</p>

Digital transformation starts in the work between systems

<p>Old software can be expensive to change and still contain business knowledge worth keeping. Its age tells you to investigate; it does not decide whether to replace it.</p><h2>Name the constraint</h2><p>Separate a slow user task from a slow development process. A page that loads badly, an integration that repeatedly fails and a product that takes months to change may need different interventions.</p><p>Describe the operation to measure and the conditions of the test. “Make it faster” leaves too much open. “Load a customer’s order history with this volume of records” gives the team something it can investigate and repeat.</p><h2>List what depends on the current behavior</h2><p>Include reports, scheduled jobs, exports, permissions and manual checks outside the application. Ask experienced users which exceptions the documentation leaves out. For every dependency, identify an owner and a way to check it after the change.</p><h2>Compare the transition, too</h2><p>Keeping the system means accepting some maintenance and limits. Improving it may remove a specific constraint. Replacing it adds migration and reimplementation work. A staged replacement also creates temporary responsibilities for data shared between old and new components.</p><p><a href="/case-studies/merp-prep-software-modernization">MERP/PREP</a> required a full rewrite across web, mobile and backend, with DevOps and migration in the same engagement. That scope followed the product’s needs; it is not the default recommendation for every older application.</p><p>A useful <a href="/digital-transformation">modernization assessment</a> should explain what to retain, improve, replace and retire, along with the evidence that could change the recommendation.</p>

Keep, improve or replace your existing software?

<p>A proof of concept, a prototype and an MVP answer different questions. Choosing the wrong one can produce an impressive demonstration without reducing the uncertainty that matters.</p><h2>A PoC tests a technical question</h2><p>Use a proof of concept when the unknown is whether an approach works under relevant conditions. For example, can an external service return the records you need with the permissions available to the application?</p><p>Write down the test conditions and success criterion first. Use representative inputs and record shortcuts. A successful API request does not establish error handling, monitoring, maintainability or readiness for production.</p><h2>A prototype tests an interaction</h2><p>A clickable prototype lets people try a task before the team implements it. Watch where they hesitate, what they expect a control to do and which information is missing. Test the task rather than asking whether they like the design.</p><p>Use the result to change the flow or clarify the behavior. A polished prototype does not, by itself, show that anyone will adopt or pay for the product.</p><h2>An MVP puts a limited product into use</h2><p>An MVP needs a defined audience and a complete first task. It can leave features for later, but it still needs the access, reliability and support required for that task. Decide which usage and business evidence will justify another release.</p><h2>End the experiment with a decision</h2><p>Record what worked, what failed and what remains unknown. The next step may be implementation, a narrower test or stopping that direction. Our <a href="/discovery">discovery</a>, <a href="/product-design">design</a> and <a href="/mvp">MVP work</a> start with the question the activity needs to answer.</p>

PoC, prototype or MVP: choose the question first

<p>This company update records Perspective Unity’s earlier feature by Clutch. We have kept its original publication date as part of the news archive.</p><p>For a current view of client feedback, read the individual engagements on <a href="https://clutch.co/profile/perspective-unity">our Clutch profile</a>. Look at the customer’s role, the work described and when the review was written.</p><h2>Use the projects to judge the fit</h2><p>Our <a href="/case-studies">case studies</a> describe the scope behind the names: custom ERP workflows for ZMatic, booking and field operations for ParkFly, workforce software for Decathlon Bulgaria, and a web and mobile platform rebuild for MERP/PREP.</p><p>If one resembles your situation, ask us about the starting point, the difficult dependencies and our responsibility in the delivery. Recognition can introduce a team; those details are what help you choose one.</p>

Perspective Unity featured by Clutch

<p>A software assessment should leave you able to make a decision. A long report that lists problems without explaining what to do next has not finished the job.</p><h2>Start with evidence already in the business</h2><p>Application access, spreadsheets, support issues, forms and reports give the review a starting point. Pick a real scenario and follow it through those sources before asking people to explain the entire operation in a workshop.</p><p>Keep the finding separate from the diagnosis. “The same customer appears twice in this export” is an observation. “The integration creates duplicates” is a hypothesis until the team has checked how those records were created.</p><h2>Show what a recommendation would preserve</h2><p>Assessment should not assume replacement. <a href="/case-studies/document-management-system%E2%80%93dms">ECONT’s document platform</a> used existing sign-on and ERP permissions. The new capability had to fit into that arrangement, not introduce a separate identity model.</p><p>For each proposed change, ask which problem it addresses, what stays in place and which dependency could prevent delivery. An integration, a process change or a targeted repair may be a better first scope than a new application.</p><h2>Ask for a decision you can review</h2><p>The output should name the options, the recommended approach, the evidence behind it and the assumptions still open. If the estimate depends on a third-party API or the condition of the data, the report should propose a specific check.</p><p>Agree the required depth before the assessment begins. Sometimes you need an options review; sometimes you need prototypes, architecture and detailed requirements. <a href="/consulting">Discuss the decision with us</a>, then define the work needed to support it.</p>

What a useful software assessment should produce

<p>A brochure website and a customer operations platform can both run in a browser. That does not make them the same development problem.</p><h2>Where a template earns its place</h2><p>For a site that mainly publishes information and takes enquiries, an existing platform or template may cover much of the structure. The remaining work still includes content, design adaptation, forms, accessibility checks, analytics and maintenance.</p><p>Ask who will edit the site and what changes they expect to make. A design that looks good on launch day is less useful if the team cannot update its own content.</p><h2>Where the work moves beyond the template</h2><p>A different problem appears when the website needs to share stock, bookings, customer records or permissions with other systems. The visual template tells you little about how those connections will behave.</p><p>In <a href="/case-studies/cupffee-ecommerce-crm-integrations">our Cupffee work</a>, the integration scope included Zoho product mapping and DHL and DPD delivery calculations. Product sizes and packaging quantities mattered behind the storefront. A comparison based only on page design would miss that work.</p><h2>Compare the same scope</h2><p>Ask both teams to show how their proposal handles your actual requirements. Separate what is included, what needs configuration, what needs development and what cannot be supported. Include licenses, migration, testing, maintenance and access to your data.</p><p>A standard platform, an extension and a custom application are all possible answers. Choose the one that fits the operating requirements and the changes you expect. If the difficult part is the workflow between systems, <a href="/core-business-solutions">start the discussion there</a>.</p>

Custom website or template: where is the work?

<p>Before estimating screens, agree what the first user must be able to finish. A product can look complete in a presentation and still leave the last step to an email or spreadsheet.</p><h2>Describe the task from beginning to end</h2><p>Who starts it? What information do they need? Who receives the result? For a booking service, taking a reservation is only the beginning: someone has to deliver it, handle changes and know whether the information is current.</p><p>That distinction mattered in <a href="/case-studies/custom-crm-platform">ParkFly Geneva’s CRM</a>. Customer bookings needed to connect to availability and mobile access for the team on the ground. The internal workflow belonged in the product scope.</p><h2>Bring examples, including the difficult ones</h2><p>Give the team representative records, current screens and documents. Show a normal task and one that goes wrong. An amended order or a duplicate customer often reveals more about the requirements than a list of feature names.</p><p>Keep three things separate: what the business knows, what it assumes and what the team needs to test. A prototype can clarify an interaction. A working integration can test a technical dependency. Neither proves that customers will buy.</p><h2>Agree who can decide</h2><p>Name the person responsible for priorities and the people who can confirm the business rules. Agree how the team will review progress, what acceptance requires and how a change affects the scope. Include access, data migration and support in the release plan.</p><p>Before committing to the build, you should be able to describe the first task, its boundaries, the dependencies and the evidence that will guide the next investment. <a href="/discovery">Our discovery work</a> turns that material into a delivery scope.</p>

When spreadsheets become an operating system

Find the rules, including the overrides

Do not turn every tab into a screen

Move the data and the responsibility

More from the Blog