<h2>Compare a working solution, not a license</h2><p>The choice is not simply a software license versus a development quote. Both approaches need a path from the current operation to a system the team can use.</p><h2>Start with the important workflows</h2><p>Identify the rules that are genuinely specific to the business and the areas where standard practice would work. A packaged platform may cover common needs well; custom development may be relevant where the differences are material.</p><h2>Include the exceptions and integrations</h2><p>Show both options the same examples: amended orders, partial payments, duplicate records and the systems that must remain. Ask how those cases will be handled and maintained.</p><h2>Make implementation visible</h2><p>Compare configuration or development, data migration, testing, training, rollout and support. Record what the quote excludes and who owns each dependency.</p><h2>Look beyond the first release</h2><p>Consider licenses, access to the code and data, supplier dependence, maintenance and the cost of expected changes. Custom is not automatically cheaper; an existing platform is not automatically simpler to implement.</p><h2>Choose around the business</h2><p>A hybrid approach may preserve useful software and add the missing workflows. The recommendation should explain the fit and trade-offs, rather than begin with a preferred technology.</p><h2>Run a comparison using your own examples</h2><p>Prepare a small evaluation pack before asking vendors for a demonstration. Include a normal order, an order amended after approval, a partial delivery and a record with incomplete information. Choose examples that reflect your business, with sensitive data removed where appropriate.</p><p>Ask each team to walk through the same cases. Record which behavior is available, which requires configuration, which needs custom work and which is unsupported. This makes differences visible without relying on a long checklist of feature names.</p><h2>Clarify the implementation boundary</h2><p>Identify the systems that will remain, such as accounting or a specialist operational tool. For each integration, agree data ownership, identifiers, the direction of updates and the handling of failures. Include a way to investigate a transaction that has not arrived as expected.</p><p>Treat migration as a defined workstream. Determine what history needs to move, who will clean the data and how the result will be reconciled. Ask for a rehearsal and an explanation of the checks before the production change.</p><h2>Compare ownership after launch</h2><p>Discuss who can change the system and what access the business receives to its data, configuration and source code where relevant. Establish responsibility for maintenance, support and the integrations. Record the terms that affect a future move to another provider.</p><p>A credible comparison also includes the changes you already expect. Consider how a new approval rule, business unit or reporting requirement would be delivered and supported. The answer should identify assumptions rather than promise that all future changes will be simple.</p><h2>Make the recommendation reviewable</h2><p>Summarize the options against the important workflows, implementation effort, recurring costs, constraints and remaining uncertainty. Separate known scope from work that still needs investigation. A decision can then be based on fit and ownership across the project, rather than the appearance of the demonstration.</p><p>For an example of the type of operational work involved, read our <a href="/case-studies/marketing-agency-erp-development">ZMatic ERP case study</a>. Its starting point was complex spreadsheet-based operations; your own recommendation should reflect the differences in your business.</p><p><a href="/custom-erp-development">See the related work and approach</a>.</p>

Custom ERP or an off-the-shelf platform?

<h2>Find the business inside the files</h2><p>Spreadsheets often begin as a practical answer and grow into a connected system. Formulas, tabs and manual steps can carry rules that are not written down anywhere else.</p><h2>Follow a real example</h2><p>Trace a customer, order or report through the files and people involved. Identify repeated entry, version conflicts and decisions that depend on someone knowing the workaround.</p><h2>Separate the rule from its current format</h2><p>Do not assume every sheet should become a screen. Work out what the information means, which record owns it and what should happen when it changes.</p><h2>Plan the transition</h2><p>Define cleanup, mapping, import and reconciliation. Test representative records and important exceptions. Agree when the new system becomes the source of truth and how the team will learn the workflow.</p><h2>Use a relevant example</h2><p>Our published ZMatic case describes replacing an interconnected spreadsheet setup with a custom ERP. The interesting part is the translation of rules and dependencies into a database and usable operational flows.</p><h2>Start with a useful scope</h2><p>A focused workflow can provide a sensible first boundary if it can operate clearly alongside the remaining tools. Include migration, permissions and support in that boundary.</p><h2>Find the rules inside the workbook</h2><p>Start by following the work that the spreadsheet supports. Identify who enters information, which formulas or lookups affect a decision and where a result is copied into another tool. Include hidden columns, manual corrections and the files people use alongside the main workbook.</p><p>Keep a copy of the original material and choose representative examples. A formula may encode an important exception, while a manual override may reflect a rule that has never been documented. Confirm the intended behavior with the people who perform the work.</p><h2>Turn exceptions into explicit behavior</h2><p>Consider an illustrative order workflow: an order is approved, one item becomes unavailable, and the customer agrees to a partial delivery. The replacement system needs a defined response for the order status, the remaining quantity, related documents and the information sent to finance.</p><p>Writing down these cases helps distinguish a simple data table from an operational application. Define the relevant roles and permissions, and agree which changes need a record of who made them and why.</p><h2>Move the data with a reconciliation plan</h2><p>Decide which records will move and how their identifiers map to the new system. List incomplete or conflicting entries and assign responsibility for resolving them. Keep unresolved exceptions visible rather than silently filling gaps with guessed values.</p><p>Rehearse the migration and compare business totals and relationships as well as record counts. Test a selection of complete scenarios using the imported data. Agree the checks, the release sequence and the conditions for returning to the previous setup if needed.</p><h2>Plan the first period of use</h2><p>The people doing the work need clear guidance on which system to use, how to report a problem and where to find support. If both systems remain active temporarily, specify which one owns each record and how differences will be handled.</p><p>Our <a href="/case-studies/marketing-agency-erp-development">work with ZMatic</a> illustrates a move from interconnected spreadsheets to a custom ERP. The useful starting point for a similar project is understanding the rules and handoffs before designing their replacement.</p><p><a href="/case-studies/marketing-agency-erp-development">See the related work and approach</a>.</p>

When spreadsheets become an operating system

<h2>Count the unknowns as well as the screens</h2><p>Two systems with similar interfaces can contain very different rules and dependencies. An estimate needs to explain what is known about the existing product and what still needs investigation.</p><h2>Understand what must be preserved</h2><p>Business behavior, data history, reports, permissions and integrations all affect the scope. Decide which capabilities must remain compatible and which will deliberately change.</p><h2>Price the transition</h2><p>Include data preparation, migration rehearsals, reconciliation, user training and release planning. Keeping old and new components connected during a phased transition also creates work.</p><h2>Separate improvement from replacement</h2><p>A targeted change and a full replacement are different investments. Compare the options against the business constraint rather than assuming the largest rebuild produces the best result.</p><h2>Ask what the estimate commits to</h2><p>Look for scope, assumptions, exclusions, acceptance criteria and responsibilities. Understand how changes and newly discovered requirements will be handled.</p><h2>Use discovery to reduce uncertainty</h2><p>An initial review can expose the dependencies that would otherwise emerge during delivery. It should produce a clearer recommendation and basis for the next commitment, not a universal price for modernization.</p><h2>Break the estimate into work that can be examined</h2><p>Ask for the estimate to distinguish investigation, design, implementation, integrations, data migration, testing and rollout. The exact work depends on the product, but naming it helps reveal omissions and dependencies.</p><p>For each area, identify what is known, what is assumed and what still needs access or evidence. A cost range should explain the uncertainty that creates the range. A fixed amount is useful only when the scope and the responsibility for changes are understood.</p><h2>Inspect the dependencies that can change the scope</h2><p>An undocumented integration, inconsistent data or a workflow known by only one person can require investigation before a reliable implementation estimate is possible. Ask the team to propose a specific check and explain which decision the result will inform.</p><p>Access to the current application, source code, infrastructure and representative data can affect what can be verified. Record access dependencies in the plan, including the people who can provide clarification or approve an external change.</p><h2>Include transition and ongoing ownership</h2><p>The cost of changing the software includes how the business will move to it. Discuss migration rehearsals, temporary operation across systems, training, support after release and the conditions for a rollback. These activities need an owner and an explicit place in the scope.</p><p>Also clarify what happens after the first release: hosting, third-party services, maintenance, monitoring and future product work. Record what is included in the engagement and what will be arranged separately.</p><h2>Use discovery to reduce a specific uncertainty</h2><p>An initial review should produce a clearer recommendation and scope, with the assumptions behind the estimate visible. Define its outputs and the questions it must answer before agreeing to it. Discovery has value when it improves a decision, not merely when it produces more documentation.</p><p>We do not publish a universal modernization price because existing systems and transition requirements differ. Bring the current situation and the intended outcome to a <a href="/contacts">project conversation</a>; the next step should identify what needs to be understood before a delivery commitment.</p><p><a href="/digital-transformation">See the related work and approach</a>.</p>

What actually shapes a modernization estimate?

<h2>Start with the decision</h2><p>A product strategy is useful when it helps a team choose what to do and what to leave out. “Build a platform” describes an activity. “Help customers repeat an order without calling the operations team” describes a problem that can guide priorities.</p><h2>Make the current work visible</h2><p>Look at how the task happens today. Review the documents, systems and workarounds before starting a long list of features. Speak with the people involved to understand the exceptions and the consequences of getting the work wrong.</p><h2>Write down the assumptions</h2><p>Separate what you know from what you expect. Who has the problem? How often does it occur? What would a useful improvement look like? Which part is uncertain enough to change the investment decision?</p><h2>Choose the next piece of evidence</h2><p>A prototype can help explore an interaction. A technical check can test an integration. A small release can show whether people use the product. These answer different questions; choose the work around the uncertainty.</p><h2>Keep the strategy connected to delivery</h2><p>Agree the first useful scope, its success criteria and the point at which you will review the evidence. Treat the strategy as a basis for making decisions as the work develops.</p><h2>Turn a problem into a decision</h2><p>Start with a workflow that the team can describe in concrete terms. Who starts it, which information is needed, what decision is made and how does the work finish? Record where people repeat an entry, wait for approval or work around missing information. These observations give a proposed feature a reason to exist.</p><p>For example, “add a customer dashboard” leaves the purpose open. “Let the operations team see which bookings need intervention before the next shift” identifies a user, a decision and a useful moment. This is an illustrative requirement, not a claim about a particular project.</p><h2>Make the first release a complete slice</h2><p>A release can be small and still complete an important task. Follow the proposed scope from its entry point to its result, including permissions, exceptions and the information that must return to another system. A collection of disconnected screens can leave the actual work unchanged.</p><p>For each proposed capability, record the problem it addresses, the evidence behind it, its dependencies and the condition for accepting it. Keep later ideas in a separate list so that agreeing a direction does not silently commit the team to every suggestion.</p><h2>Use a strategy that can be revised</h2><p>Agree which assumptions need evidence before development begins and which can be tested through an initial release. An integration with an undocumented system may need a technical check; a confusing user workflow may need a prototype and observation.</p><p>A useful strategy identifies the decision owner, the starting scope, the remaining uncertainty and the next review point. When evidence changes, revisit the affected decision explicitly. Keep a short decision log so that the team can understand why the plan changed.</p><p><a href="/discovery">Explore the next step with Perspective Unity</a>.</p>

A product strategy starts with a decision

<h2>Start with what must keep working</h2><p>An older product may be difficult to change and still contain valuable business knowledge. Before choosing a new stack, identify the workflows, calculations, permissions and integrations that users depend on.</p><h2>Look beyond the code</h2><p>Review representative records, reports, documents and support issues. Ask users about the exceptions: failed payments, partial deliveries, corrections and records that do not match. These are often where the important rules become visible.</p><h2>Choose the boundary of change</h2><p>Some problems call for a better interface or targeted improvements. Others require new components or a replacement. Compare the options against the required capabilities and the practical cost of keeping old and new parts connected.</p><h2>Make migration a testable part of delivery</h2><p>Define how records map, which information must reconcile and how you will check completeness. Rehearse the migration with representative data. Resolve discrepancies before treating the import as finished.</p><h2>Plan the release, including failure</h2><p>Agree when the new system becomes authoritative, how users move over and what the team will do if a critical check fails. Phased rollout and parallel operation can help in some architectures; both add responsibilities that need to be designed.</p><h2>Measure the change that mattered</h2><p>Use the original problem to judge the result: time to make a change, a difficult user task, an operational bottleneck or an agreed reliability measure. A new technology name is not itself the business outcome.</p><h2>Establish what the current system does well</h2><p>Begin with the workflows that already support the business. Record their users, rules, inputs, outputs and dependencies before deciding which technology to replace. Include the work that happens outside the application, such as reconciliations in spreadsheets or approvals sent by email.</p><p>This baseline helps distinguish a technical limitation from an unclear process. It also gives the team a way to judge whether a proposed change preserves the useful behavior of the existing system.</p><h2>Choose where to intervene</h2><p>The next step might be a targeted improvement, an integration, a replacement of one part of the product or a broader rebuild. Compare those options against the actual constraints: access to the source code, dependencies, operating costs, data quality and the availability of people who understand the system.</p><p>Before promising a faster product, define the operation to measure and the conditions of the measurement. Loading a customer history, importing a file and completing an overnight calculation are different problems. A baseline and a repeatable test make the result understandable.</p><h2>Plan the transition as part of the work</h2><p>Identify which records move, how identifiers will be matched and who resolves exceptions. Rehearse a migration with a copy of representative data and compare the business results, including totals and relationships, rather than relying only on the number of imported rows.</p><p>For a staged transition, define which system owns each record while both remain in use. Include a support plan, access arrangements, a rollback decision and checks after release. A release is ready when the team can operate and support the changed workflow, with known limitations recorded.</p><p><a href="/digital-transformation">Explore the next step with Perspective Unity</a>.</p>

How to modernize software without losing the business rules

<h2>Start with the customer task</h2><p>A startup needs a product that can test a meaningful proposition. Decide who the first users are, which task the product will help them complete and why they would choose it over their current approach.</p><h2>Keep the first scope coherent</h2><p>A smaller product still needs a complete experience. Include the access, error handling and support required for the selected workflow. Removing half the workflow can make a release smaller without making it useful.</p><h2>Agree responsibilities early</h2><p>A delivery partner can lead research, design, engineering and testing within the agreed scope. The founding team still owns business priorities, access to customers and decisions about the proposition. Name the people who can make those decisions.</p><h2>Use progress to learn</h2><p>Review prototypes and working releases against real tasks. Keep feedback connected to the original assumptions so that requests can be assessed rather than simply added to the backlog.</p><h2>Plan the day after launch</h2><p>Decide how users will receive help, how issues will be handled and what evidence will inform the next investment. Launch creates a new set of product questions; it does not settle them.</p><h2>Clarify the evidence you need next</h2><p>A new product can contain several different uncertainties: whether the problem matters, whether users can complete the proposed workflow and whether the technical dependencies are workable. Decide which uncertainty the next investment should reduce.</p><p>Interviews, a prototype, a technical experiment and a first release answer different questions. Choose the smallest useful activity for the question at hand, and define what would count as enough evidence to continue, change direction or stop.</p><h2>Define the operating scope</h2><p>Even an initial product needs rules for access, data and failure. Identify who can see and change information, how an account is created, what happens when an integration fails and how support will investigate a problem. Include these needs when estimating the release.</p><p>Avoid using the word MVP as a substitute for a scope. Name the users, the task they will complete, the environments involved and the boundaries with external systems. Write down the capabilities that are deliberately left for later.</p><h2>Make delivery and learning visible</h2><p>Agree acceptance criteria before a capability is considered complete. The development team should test the implementation, while the business checks that the behavior fits the intended operation. Prepare real examples and exception scenarios for that review.</p><p>After launch, connect feedback to a decision. A support request might reveal an unclear screen, a missing rule or a feature for a later release. Record the evidence and the affected workflow before expanding the roadmap. This keeps the product connected to its purpose as more ideas arrive.</p><p><a href="/mvp">Explore the next step with Perspective Unity</a>.</p>

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

<h2>Name the operational problem</h2><p>“Digital transformation” is too broad to define a useful first scope. Start with a recurring problem: people re-enter an order, documents arrive too late, or finance cannot reconcile what operations has completed.</p><h2>Follow one real transaction</h2><p>Trace an example from its beginning to its final outcome. Include the people, documents and systems involved. Record where information is copied, where a decision is made and where the current tools lose the context.</p><h2>Include the exceptions</h2><p>A process that works only for the straightforward case is incomplete. Ask what happens when an order changes, a payment is partial or a record is duplicated. Agree who resolves each exception and which system holds the authoritative information.</p><h2>Choose the appropriate change</h2><p>The answer may combine a process adjustment, an integration and a new application. Compare the effort of implementation and ongoing ownership, rather than assuming that the largest replacement is the strongest strategy.</p><h2>Deliver a useful boundary</h2><p>Choose a scope that completes an identifiable piece of work. Agree data checks, access, training and acceptance with the team that will use it. Expand after the first workflow works in practice.</p><h2>Follow the information through the business</h2><p>Choose an important workflow and trace it across the people and tools involved. For an order, that might include a quote, approval, delivery information, an invoice and a payment. Record each handoff and the checks people perform before they trust the next step.</p><p>Treat this as an investigation. A spreadsheet may contain a necessary business rule that is absent from the main application. A repeated manual check may be compensating for inconsistent identifiers. Understanding those details is part of defining a useful change.</p><h2>Agree data ownership and exceptions</h2><p>For each important record, decide which system owns it and which other systems need a copy. Define the identifier, the fields that can change and the process for resolving differences. An integration needs a response to failed, repeated or incomplete messages.</p><p>Use representative exceptions when reviewing a solution: a revised order, a partial delivery, a duplicate customer or a change after approval. These examples expose missing rules earlier than a demonstration limited to the normal path.</p><h2>Give the change an operating plan</h2><p>Select a first scope that completes a useful workflow and has manageable dependencies. Include migration, permissions, testing, training and responsibility after release in the same plan as the software changes.</p><p>Define the outcome in business terms and record its starting point. The measure might concern a delay, a reconciliation task or the availability of trusted information. Review the result against the agreed measure and the experience of the people using the system, then decide the next improvement.</p><p><a href="/core-business-solutions">Explore the next step with Perspective Unity</a>.</p>

Digital transformation starts in the work between systems

<h2>Age is a signal, not the decision</h2><p>An old system can still serve the business well. A newer one can still be difficult to operate. Assess the software against the tasks, changes and reliability the business needs now.</p><h2>Identify the constraint</h2><p>Separate problems of usability, code, infrastructure, data and process. If people repeat work because two tools do not share information, an integration may address the problem more directly than a full replacement.</p><h2>Compare the options honestly</h2><p>Keeping the current system may require maintenance and accepted limits. Improving it may preserve useful rules while removing specific constraints. Replacing it creates opportunities, but also brings migration, reimplementation and adoption work.</p><h2>Look for hidden dependencies</h2><p>Reports, integrations and experienced users may depend on behavior that is poorly documented. Make those dependencies visible before estimating a rewrite. They affect the transition even when the final interface looks simple.</p><h2>Make a decision that can be reviewed</h2><p>Document the reason for the chosen approach and what evidence could change it. A targeted assessment should help the business decide its next investment, not automatically justify a larger rebuild.</p><h2>Build a map of dependencies</h2><p>Record the applications, scheduled jobs, files, integrations and reports that depend on the existing system. Include less visible consumers, such as an export used by finance or a document template maintained by one team. Confirm these with people who perform the work.</p><p>For each dependency, identify an owner and a way to test that it still works. This becomes part of the transition plan and helps reveal where a change that looks local could affect another workflow.</p><h2>Compare realistic transition options</h2><p>Replacing everything at once concentrates the transition into a single release. A staged approach can divide the change, but it also needs rules for synchronization and temporary operation across systems. Compare both against the actual data and workflow boundaries.</p><p>Record what will be retained, replaced, integrated and retired. Explain how the recommendation handles the main risks, what evidence is still missing and which decisions must be made before a delivery estimate can become reliable.</p><h2>Rehearse and reconcile</h2><p>Test a migration using representative data, including incomplete and unusual records. Agree which differences are acceptable and which must be resolved before release. Verify relationships and business totals as well as record counts.</p><p>During the release rehearsal, test access, integrations, critical workflows, backups and the decision to restore the previous version if necessary. Name the people responsible for the checks and for resolving issues. After release, keep a clear path for reporting problems and deciding whether they are defects, data corrections or new requirements.</p><p><a href="/digital-transformation">Explore the next step with Perspective Unity</a>.</p>

Keep, improve or replace your existing software?

<h2>Three tools, different questions</h2><p>A proof of concept explores whether a technical approach is feasible. A prototype explores an interaction or design. An MVP puts a focused product into use so a team can learn from real behavior. The useful choice depends on what you need to know next.</p><h2>Use a PoC for a technical uncertainty</h2><p>For example, test whether a particular integration can provide the required information under representative conditions. Define a success criterion and the limits of the test. A successful experiment is not a production-ready system.</p><h2>Use a prototype to examine a workflow</h2><p>Let people attempt a task and explain what they expect to happen. Explore decisions, misunderstandings and missing states before investing in the full implementation. A polished prototype does not establish market demand on its own.</p><h2>Use an MVP to learn from use</h2><p>Build a limited but coherent experience for a defined group of users. Agree how usage, feedback and business evidence will inform the next decision. Essential reliability and support still matter.</p><h2>Stop when the question is answered</h2><p>Avoid turning every experiment into a miniature full product. Record what was learned, what remains uncertain and whether the evidence supports the next investment.</p><h2>Write the question before building the experiment</h2><p>A useful proof of concept has a specific uncertainty to resolve. For example: can an existing service provide the information needed for a workflow under the relevant access restrictions? That question is narrower than “can we build the product?” and can be tested with a defined setup.</p><p>Record the assumption, the test conditions, the evidence to collect and the result that would support the next decision. Include a limit on the experiment so that it does not quietly become an unfinished implementation.</p><h2>Use representative conditions</h2><p>Choose inputs that reflect the difficult parts of the intended use, not only a clean example. Consider the size and quality of the data, integration limits, permissions and relevant exception cases. Explain any shortcuts taken in the experiment.</p><p>A prototype can help people judge a proposed interaction. A technical proof of concept can test feasibility. Neither automatically demonstrates that a system is ready for daily operation, and each should be described according to the question it actually tested.</p><h2>Make the result actionable</h2><p>Document what worked, what failed and what remains uncertain. If the experiment supports proceeding, identify the production work still required: error handling, security controls, monitoring, maintainability, testing and operation within the rest of the system.</p><p>If the result is mixed, recommend a smaller follow-up test or an alternative approach. A useful outcome can be a decision not to pursue a costly direction. The value comes from reducing uncertainty before a larger commitment, with evidence that another reviewer can understand.</p><p><a href="/discovery">Explore the next step with Perspective Unity</a>.</p>

PoC, prototype or MVP: choose the question first

<h2>A company update from the archive</h2><p>This article records an earlier Clutch feature about Perspective Unity. It belongs in our company news archive, with the original publication date preserved.</p><h2>What the recognition can tell you</h2><p>Client feedback can add context to a company’s work. To assess a delivery partner, read the individual review, the engagement it describes and the date, alongside relevant project examples.</p><h2>Look at the work as well</h2><p>Our case studies describe systems built for specific businesses, including the problem, the approach and the delivered capabilities. They are a useful next step when considering whether our experience fits your project.</p><h2>Use recognition as a starting point for due diligence</h2><p>An award or review can introduce a company, but a buyer still needs to understand the team, the work and the fit for a particular project. Read the context of a review and compare it with the kind of engagement you are considering.</p><p>Ask what problem the team addressed, which responsibilities it owned and what the customer contributed. Look for a clear explanation of the implementation and its limitations. A recognizable client name on its own does not establish the scope of the relationship.</p><h2>Ask about the work behind the description</h2><p>For a relevant case study, discuss the starting situation, the constraints and the difficult decisions. Find out how requirements were clarified, how integrations and data were handled, and how the team tested the result before release.</p><p>At Perspective Unity, our published work includes business systems for customer operations, workforce processes, card management and document access. Use those examples to start a conversation about the similarities and differences with your own situation.</p><h2>Judge the proposed working relationship</h2><p>A useful proposal should make the initial scope, responsibilities, dependencies and review points clear. Ask how the team will handle unknowns and how it distinguishes a defect from a change in requirements.</p><p>You should be able to understand the recommendation and the assumptions behind it. Recognition can support an initial conversation; the evidence from relevant work and the clarity of the proposed engagement help you make the actual choice.</p><p><a href="/case-studies">Explore the next step with Perspective Unity</a>.</p>

Perspective Unity featured by Clutch

<h2>Begin with the material that already exists</h2><p>Software, spreadsheets, forms, reports and support issues often contain the starting point for an assessment. Reviewing them first makes conversations more specific and avoids asking people to reconstruct the whole business from memory.</p><h2>Follow a representative workflow</h2><p>Choose a real example and trace the decisions, information and handoffs it requires. Ask the people involved about exceptions and the work they perform outside the official process.</p><h2>Separate observations from assumptions</h2><p>Document what the evidence shows and what still needs confirmation. A suspected bottleneck is a question to investigate, not yet a measured business loss.</p><h2>Produce a recommendation</h2><p>Explain the practical options and trade-offs. The recommendation may involve a process change, an integration, improvements to existing software or a new system. Include the dependencies and unknowns that affect delivery.</p><h2>End with a usable next step</h2><p>The output should help someone make a decision: a defined scope, further technical investigation, a prototype or a decision to leave part of the current setup in place. Agree the depth of the assessment before it begins.</p><h2>Bring existing evidence into the review</h2><p>Gather the material that already describes the operation: forms, reports, process notes, screen recordings, support issues and representative records. Include the current software and the tools used around it. The review should build on this material before asking people to repeat it in workshops.</p><p>Follow a small number of important scenarios from beginning to end. Record differences between the documented process and the actual work, and ask why those differences exist.</p><h2>Separate observations from recommendations</h2><p>Keep a clear distinction between a confirmed limitation, an assumption that still needs investigation and a proposed change. Attach evidence to the important findings so that the business can assess the recommendation.</p><p>A recommendation should connect a problem to an option, its expected effect, dependencies and main risks. Sometimes the practical next step is to clarify a rule or improve an integration rather than start a new application.</p><h2>Finish with a decision-ready scope</h2><p>The output should help the business choose its next investment. It can include a workflow map, a prioritized problem list, an outline of the options and an initial delivery scope with assumptions.</p><p>Agree which questions remain open and who can answer them. If a cost or timeline depends on an unknown integration or data condition, state that dependency directly and propose how to investigate it. Review the plan when new evidence changes a material assumption.</p><p><a href="/consulting">Explore the next step with Perspective Unity</a>.</p>

What a useful software assessment should produce

<h2>Start with the purpose of the site</h2><p>A straightforward marketing website and an operational web application have different needs. Identify what visitors and the internal team need to do before comparing implementation approaches.</p><h2>Where a template can help</h2><p>An established template or platform can provide a useful starting point when its structure and capabilities fit the job. Content, accessibility, analytics, integrations and maintenance still require attention.</p><h2>When custom work becomes relevant</h2><p>Unique workflows, specialist integrations or a different editing model may create work that a template does not solve. That work may call for an extension, a hybrid approach or a custom application, depending on the constraints.</p><h2>Compare the full investment</h2><p>Include setup, design adaptation, content migration, licenses, testing, ongoing maintenance and future changes. A low initial build price does not describe every cost; custom development is not automatically cheaper either.</p><h2>Make the recommendation specific</h2><p>Choose the approach around the work the site must support. If you are deciding on a business system rather than a marketing website, assess its operational rules and data needs separately.</p><h2>Compare the same operating requirement</h2><p>Start by describing what the website or product must enable. Publishing information, taking a straightforward enquiry and managing a complex operational workflow are different scopes. A comparison is useful when both options are evaluated against the same requirements.</p><p>List the essential interactions, permissions, integrations, content needs and expected changes. Ask how each approach handles them and what work is excluded from the initial quote.</p><h2>Include the work around the software</h2><p>A ready-made product may require configuration, extensions, integration and data migration. Custom development needs its own design, implementation, testing and maintenance. Account for these activities instead of comparing only a subscription with a development estimate.</p><p>Consider who will manage content and operations after launch. Confirm access to the data, the ability to export it and the responsibility for updates. These details affect how easily the business can change direction later.</p><h2>Choose the scope that fits</h2><p>A standard platform can be a good choice when its behavior matches the important needs and its limits are acceptable. A custom application may make sense where the operating rules and integrations justify the additional work. A combination can also preserve useful tools while adding the missing workflow.</p><p>Ask the delivery team to explain its recommendation using your requirements and likely changes. The choice should be understandable without assuming that one approach is always better. Start with a bounded scope and a clear plan for testing the result.</p><p><a href="/consulting">Explore the next step with Perspective Unity</a>.</p>

Custom website or template: where is the work?

<h2>Who is it for, and what changes?</h2><p>Name the first users and the task the product should help them complete. Describe their current approach and why they would change it.</p><h2>What needs to be true?</h2><p>Record the business and technical assumptions behind the idea. Identify which uncertainties could change the decision to build.</p><h2>What is the first useful scope?</h2><p>Choose a complete workflow for a limited audience. Include the essential access, error handling and support that make it usable.</p><h2>What does it depend on?</h2><p>List the data, integrations, permissions, people and commercial decisions required to deliver. Assign responsibility for making them available.</p><h2>How will you judge the result?</h2><p>Agree what acceptance means and what evidence will guide further investment. Keep implementation testing separate from evidence about customer demand.</p><h2>Who owns the product after launch?</h2><p>Decide how feedback, incidents, maintenance and new priorities will be handled. A launch without ongoing responsibility leaves important work unfinished.</p><h2>Give the team concrete starting material</h2><p>Bring examples of the problem, the people affected and the work they need to complete. If a system already exists, include access to representative screens and records, documentation and the issues the team encounters. This material helps turn an idea into a scope that can be discussed.</p><p>Define the decision owner and the people who understand the workflow. Agree how they will resolve conflicting requirements and who can confirm the business rules.</p><h2>Connect scope, dependencies and acceptance</h2><p>Describe a complete first use case, including how it starts and ends. Identify the external systems, data sources, permissions and operational steps it depends on. Record which dependencies are available and which require investigation.</p><p>Write down the acceptance criteria alongside the scope. Include important exception cases and the evidence needed to show that the software behaves as agreed. The development team should perform implementation testing before asking the business to validate the workflow.</p><h2>Prepare for the product to be used</h2><p>Plan data migration, training, access and support before treating the release date as settled. Agree how issues will be reported and how the team will decide whether they require a correction or a later improvement.</p><p>Finally, define the next review after launch. Compare the result with the original problem and the experience of the users. A useful product plan includes the decisions and responsibilities that keep the software working as the business changes.</p><p><a href="/discovery">Explore the next step with Perspective Unity</a>.</p>

Useful thinking for your next software decision