A written assessment of whether to build, buy or configure, delivered before any budget is committed
Before money reaches a vendor, you receive a written assessment of whether to build, buy or configure. It comes with a requirements document, architecture advice, a phased roadmap and a costed budget. Any vendor can build from it.
- Written for any vendor to build from, GullySystem included
- Written findings plus a working session to discuss them
- Confidentiality agreed in writing before discovery begins
Manufacturers use it to decide whether to extend a licensed ERP or replace a plant spreadsheet. Distributors weigh a packaged product against software built around their own trade discounts, price tiers and dealer rates, and they ask us which one fits. Clinics and schools use it too. So do founders holding a quotation they cannot judge. Some engagements end in a build plan. Others find that a licence and a short configuration exercise is the better route, or that a half-finished project can be completed instead of restarted.
Where technology decisions are taken without enough information
Quotations That Cannot Be Compared
Two or three vendors quote for the same brief, yet each defines the scope differently, so no line in one quotation can be matched to a line in another. Price or presentation decides. Change requests follow.
Different Scope Assumed by Each Department
The requirement lives in notes and chats. Accounts assumes a credit check is included and a branch assumes stock is, while the vendor has quoted for neither, so each unsigned gap becomes a paid change request.
An Earlier Purchase With No Recorded Cause
An earlier purchase fell short. Nobody wrote down why. A new proposal is now being drafted on the same assumptions, with no record of whether the fault lay in the product, the scope or the rollout.
No One Inside to Judge the Proposal
There is no technology head, so the decision waits for an owner who is not technical, and a vendor’s pre-sales engineer slides into the role of informal advisor. That engineer recommends whatever their employer sells.
A Single Figure Without a Breakdown
The proposal gives one amount and one duration. It never shows what is excluded, which requirement drives the cost, or what licences and support will cost in the second and third year. The figure cannot be questioned.
Work Already Paid For but Not Verified
Instalments have been paid against a demo described as nearly ready, yet nobody on the client side has opened the code, the database or the server. The next move is a guess.
Replacement Decisions Deferred Each Year
Everyone expects the spreadsheets to go someday. The decision slides into next year. Nobody has recorded which sheet carries which duty, what replacing it involves or what it would cost, which means postponing is a decision made with no figures behind it.
None of this is a technology problem yet. These are decisions taken on incomplete information. A structured assessment has a defined scope and a fixed fee, whereas a wrong decision carries the cost of every month of development that follows it.
A written plan for approval, challenge or handover to any vendor
We start with the business, not a technology proposal. We meet the staff doing the job and read the systems, contracts and figures already in place. Then we write up the actual problem, what it costs in your own figures and what solving it involves. The verdict follows. Build, buy, configure or wait.
The Problem Before the Product
No platform gets named until the situation is understood. We map how an order, a job card or a patient record moves today, where it stalls and who re-keys what. Sometimes the step worth funding is a different one.
Build, Buy or Configure Compared Both Ways
Every recommendation arrives with the case against it. Options are compared on three years of licences, migration, training, internal staff hours and how far the business must bend to fit a packaged product.
A Phased Plan Sized to the Budget
The roadmap is phased. Phase 1 stays small. Each phase lists its scope, dependencies and cost drivers, then ends at a decision gate where the client can continue, pause or stop.
What the engagement produces
Focus on business value before discussing technology.
A Requirement Document Vendors Can Quote Against
Scope, user roles, screens and system boundaries sit in one document, so every vendor prices the same thing and their quotations can finally be set side by side. Line matches line.
A Recorded Build, Buy or Configure Recommendation
The recommendation carries its reasoning and trade-offs in writing, so it can go in front of partners, a board or a bank manager without a rewrite. Nothing rests on memory.
A Roadmap With Stop Points
The phase treating the largest pain comes first. Each phase ends at a gate, and that gate records whether the next phase is still worth funding given what the first one revealed.
A Budget Showing Its Drivers
The estimate is split by phase and names the driver behind each line, so when the total exceeds the plan, the requirement to cut is visible. Cost figures are confirmed after scoping.
Risks Recorded With Owners
Migration gaps, staff adoption, regulatory deadlines, vendor lock-in and dependence on one person all go into the register. Each risk has a named owner.
Documents That Belong to the Client
The requirement, architecture and roadmap belong to the client and are written for handover to any vendor, with no assumption that GullySystem does the build. Ownership is never in doubt.
What technology strategy and product consulting covers
Everything required from operational discovery to production deployment and long-term maintenance.
Discovery and Current-State Assessment
Structured interviews with owners, function heads and the staff doing the work, plus a review of live data, so that the record shows how the business really runs. The manual is ignored.
Business Requirement Document (BRD)
The business case, objectives, processes in scope, departments affected, legal obligations and success criteria, written in language a management team can approve. BRD stands for business requirement document.
Product Requirement Document (PRD) and Functional Specification
Features, user roles, permissions, screens, states, data fields, rules and deliberate exclusions, in enough detail for a developer to build from. The client reviews the finished product against it. Nothing is guesswork.
Build, Buy or Configure Assessment
A costed comparison of custom software, a licensed package, a configuration of something already owned, or carrying on manually for now. Each route is tested against current processes and costed over three years, with licence and subscription spend shown separately for every option.
Solution Architecture Advisory
The recommended shape of the system: modules, a data model outline, integration points, hosting, access control and a growth path. Every alternative is listed with its trade-offs written out.
Technology Stack Selection
A recommendation on languages, frameworks, database and hosting, where each choice is judged on fit, running cost, and how easily staff can be hired or a vendor replaced later.
Software Vendor and Proposal Evaluation
Proposals are restated on one common scope. You get a scorecard against your own criteria, questions for each vendor and a list of gaps in what was quoted.
Technical Due Diligence
An independent review of an existing or half-built system, covering what works, repository condition, data integrity, security exposure, dependence on individuals and what completion would involve. Nothing is taken on trust.
Automation Opportunity Assessment
A ranked list of processes to automate first, where each entry records the manual effort, the systems touched and the difficulty. The automation budget follows the list. Enthusiasm does not set it.
AI and Cloud Readiness Assessment
A view of whether your data, volumes and processes can support AI features or a cloud move yet, naming what to fix first. Weak use cases are dropped early.
Fractional CTO and Ongoing Advisory
A technology head available a few days a month. The role reviews vendor work, approves architecture decisions, joins negotiations and keeps the roadmap current, for companies that are not ready to hire full time.
Legacy Modernisation and Digital Roadmap
A multi-year sequence for replacing or wrapping ageing systems. It sets out what moves first, what waits and what is retired, so that trading carries on through every step.
Where a planning engagement applies
Real-world business processes we configure and automate.
Manufacturer Choosing Between ERP Extension and a Shop-Floor System
A components manufacturer keeps accounts in a licensed ERP, while production planning, job cards and rejections sit in loose spreadsheets on the shop floor. One vendor proposes a new MES. The ERP partner says the modules already exist. Discovery finds which shop-floor steps the licensed modules cover, which need building, and what operators can key in during a shift. The answer may be a small job-card layer.
Distributor Holding Two ERP Proposals
A regional distributor holds two ERP proposals. Both are restated on one scope and tested against how it trades, covering price tiers, trade discounts, credit limits and damaged-goods returns. Each is then costed over three years, including migration, training and the weeks of changeover when staff run two systems at once. A scorecard follows. So do exclusions and vendor questions.
School Group With Software Bought Department by Department
A group of schools runs admissions on one product, fees on another and transport on a third, so parents type the same details into each portal. The assessment decides which system holds the master student record and which products stay or go. The order keeps clear of admissions and fee collection.
Logistics Operator Reviewing a Funded App
A transport operator must decide whether to release the next instalment on a driver and consignment app funded over several months. Technical due diligence checks what code exists, whether the data is recoverable and what completion requires, and the board then sees three options costed side by side. A recommendation sits on top.
Professional Firm Planning AI Document Review
An audit firm wants AI for document review. The readiness assessment finds that the source files are scanned images, filed by client name with no consistent structure, so digitising and indexing must come first. The roadmap puts that in Phase 1. AI review follows in Phase 2.
Founder Defining a First Version
A founder has a feature list drawn from three prospective customers and a plan to build all of it before launch. Discovery separates what those conversations demand from what can wait, then produces a PRD for the smaller first version and prices each phase. Some engagements recommend running the service by hand first.
Is This Service Right for Your Business?
We partner with established businesses that have outgrown manual processes and want reliable systems.
Owners Facing a Large Technology Spend
Businesses about to commit a large sum to an ERP, a platform or a custom build, who want the decision examined by someone who is not selling the product. A second pair of eyes.
Companies Whose Last System Was Not Adopted
Organisations that bought software their staff now work around. They want the cause found before paying for a replacement that could fail the same way, and so they ask for a diagnosis first.
Businesses Without an Internal Technology Lead
Companies where the owner, finance head or operations manager judges vendors, architectures and contracts on top of their own job, with no technical peer to check the answers.
Founders Planning a Product
Founders planning a SaaS product or an app. They need the idea cut down to a defined first version, a requirement document and a phased budget before any development money moves.
Management Assessing an Existing System or Vendor
Boards, partners, buyers and investors who need an independent technical view of a system, a codebase or a delivery partner before renewing, acquiring or escalating.
When This Service Is Not Needed
If the requirement is small and clear, such as one reminder flow, one report or one form, building it directly is the better use of budget. Where a written requirement and a trusted vendor already exist, reviewing that one proposal is enough, and a report will not change a decision made on other grounds. We say so on the first call.
Enterprise Capabilities in Plain Business Terms
Process Mapping From Observation
Current-state maps are drawn from watching the work and talking to the people who do it, with the written process document kept strictly as a reference. Observation wins.
Cost of the Current Way
Manual effort, rework and delay in each process are estimated from your own volumes and staff costs, and the business case rests on those figures. No benchmark is borrowed.
Requirement Prioritisation
Each requirement is classed as essential, valuable or deferrable. We state the trade-off so Phase 1 stays inside the budget, and nothing deferrable creeps in quietly while the build is under way.
User Role and Permission Modelling
Who sees what, who approves what and who can override a decision. This is settled early, because it shapes the design and most of the later arguments between departments, from accounts to dispatch.
System Boundary Definition
A boundary around what the new system does and what stays with existing tools. Scope creep usually begins at that line. So it gets drawn first, and defended.
Three-Year Cost of Ownership
Licences, hosting, migration, training, support and internal effort are compared across all options, including the years after the quoted one. Cheap proposals often turn expensive in those years.
Architecture Options With Trade-offs
Two or three viable designs, each showing its cost, what it constrains and what it makes easier later, because a single answer offered as the only one deserves suspicion.
Data Migration Feasibility Review
Existing records are checked for duplicates, missing fields and inconsistent codes, and the review shows what can move, what needs cleaning and what stays behind in the old system.
Vendor Proposal Normalisation
Competing quotations are restated on identical scope and assumptions. Each vendor’s exclusions are listed in one table.
Code and Repository Review
For due diligence we read repository history, structure, test coverage, dependency risk and documentation, which tells us plainly whether the existing work can be built on. The finding is blunt. Build on it, or walk away.
Security and Data-Handling Review
We trace where personal, financial and customer data sits today and who can reach it, then list what the proposed design needs before it can handle that data responsibly.
Phasing and Dependency Sequencing
Work is ordered so each phase is usable alone. Tax-filing dates and business seasons are built into the sequence, so a go-live never lands in a filing month or your busiest weeks.
Our Structured 6-Step Delivery Process
A transparent path from your first conversation to a reliable production release.
- 01
Business Discovery
We interview the owner, function heads and the people doing the daily work, to establish what the business is trying to achieve and what obstructs it. We need an hour with each person, freedom for them to speak plainly, and one senior person who can settle disputes between departments.
- 02
Current-State and Cost Review
We map the processes in scope, examine the systems already running and review what technology costs today. For this we need read access or sample exports, copies of licence and vendor agreements, and last year’s technology spend, including annual maintenance contracts and subscriptions.
- 03
Options and Build-Buy Assessment
We list the realistic options and test packaged products against the actual process, costing each route over three years. We need the real constraints, which means the budget ceiling, what cannot change, and any season, audit or regulatory deadline the plan must respect.
- 04
Requirement Definition and Sign-Off
We write the BRD and, where a product is being built, the PRD, with roles, screens, rules and exclusions set out in full. Each function head reviews it and signs in writing. Every later cost and date is measured against it.
- 05
Architecture, Roadmap and Budget
We produce the recommended architecture, the phased roadmap with decision gates, the budget by phase with its cost drivers, and the risk register. We need your view on phasing, plus an honest figure for the internal hours your team can spare each week.
- 06
Decision Support and Handover
We present the findings to management, answer the challenges and hand over every document, so we need a decision meeting with the people who can approve. If you then go to market, we can help brief vendors and compare responses, whether or not GullySystem is one of them.
What You Receive Upon Project Completion
Everything required to run, maintain, and expand your software without vendor lock-in.
Connects With the Systems You Already Rely On
We build bridges between your software so you don't have to replace functional existing tools.
Systems Commonly Found in Scope
- Accounting software such as QuickBooks or Xero
- Zoho Books and Zoho One
- Odoo
- SAP Business One
- Microsoft Dynamics 365
- Industry-specific products
Packaged Options We Evaluate Against
- ERPNext
- Salesforce
- HubSpot
- Zoho CRM
- Microsoft Power Platform
- Vertical SaaS products
Data Sources We Review During Discovery
- Excel and Google Sheets registers
- On-premise SQL databases
- Billing and POS software
- Vendor portals and marketplace panels
- Email and WhatsApp records
Hosting and Infrastructure Compared
- AWS
- Microsoft Azure
- Google Cloud
- DigitalOcean
- Existing on-premise servers
- Vendor-hosted SaaS
Statutory and Compliance Context Considered
- E-invoicing and transport document rules
- Personal data protection law obligations
- Withholding tax and payroll requirements
- Sector licensing and record-keeping rules
Selected for Reliability, Speed, and Longevity
Technology chosen to match your operational scale and long-term maintainability.
Application Platforms Assessed
Data and Reporting Options
Packaged and Low-Code Routes
AI and Automation Building Blocks Evaluated
Discovery, Diagramming and Documentation
Why Business Owners Choose GullySystem
Not Building Is a Valid Outcome
A recommendation to license a product, configure what is already owned, or wait is a legitimate result. An assessment that always chose custom software would be worthless to the person paying.
Each Recommendation Carries Its Counter-Argument
We write the case against our own preferred option. A plan tested against its own weaknesses is easier to review than one that merely reads well in a presentation.
Costs Include Items Proposals Omit
Migration, training, staff hours during changeover, licence renewals and second and third year support are all counted, and those items often decide which option is genuinely the cheaper one.
Written for Management as Well as Developers
The main documents use plain business English, so an owner, a partner or a finance head can read and question them. Technical detail sits in an annexe for whoever builds.
Consulting Is Separate From the Build
The documents are yours. You may run a tender, hand the plan to an existing partner, or give it to an internal team, because the documents are written for any vendor. Consulting stays separate from the build.
Advice From a Team That Also Delivers
The team also builds, integrates and supports systems. Estimates, risks and sequencing therefore come from delivery work on real projects, not from a template applied to an industry.
Flexible Engagement Options
Choose an engagement model that matches your operational scope, budget, and timeline.
Focused Assessment
For a single bounded question, such as build or buy, one ERP or another, or whether a proposal is reasonable. You get a short written recommendation. A working session follows.
Full Discovery and Roadmap
Discovery, requirement documents, architecture, phased roadmap, budget and risk register arrive as one pack, which a board or a set of partners reviews and signs off.
Technical Due Diligence
An independent review of what exists, what works and what completion or repair involves, which also asks whether the current arrangement should continue at all.
Fractional CTO Retainer
Ongoing advisory for companies not ready to hire, covering review of vendor work, architecture decisions, negotiations and upkeep of the roadmap. A few days a month.
Frequently Asked Questions
Straightforward answers to the questions owners ask before getting started.
Is technology consulting worth paying for if we are a small business?
No, size is not the test. A structured assessment suits a sum that would hurt to lose, or a system the business will run on for years. A small, well understood requirement does not. We say so on the first call.
What actually happens during the engagement?
Interviews, observation and document review. We speak to the owner, function heads and the staff who do the work, and watch how a job moves from enquiry to payment. We also review live data, existing systems and current technology spend, and realistic options are then tested against those findings. Findings are discussed as they emerge. The final presentation holds no surprises.
Can you advise us without taking the development project?
Yes, you can. Consulting is a standalone engagement with its own fee and deliverables, and the documents are written so any competent vendor can build from them. We can help run a tender in which GullySystem takes no part, and any later build by us would be a separate agreement. Nothing is bundled.
Can you evaluate quotations, vendors or a shortlist we already have?
Yes. We restate each proposal on one common scope so the prices can be compared, and list what each vendor has excluded. The product is checked against how your business works. You receive a scorecard and the questions to put to each vendor before signing, and if a proposal looks reasonable we say so.
Can you assess a project that is half-built or has stalled?
Yes. We review what exists, not what was promised: the working software, the repository and its history, the database, data quality, documentation and dependence on one person. The result states what is usable and what completion involves, so you can decide whether to continue, move the work or stop. Repair need not come to us.
Do we have to replace the systems we already run?
Usually not. Most assessments end with some systems kept, some configured better, and a smaller gap filled by new software, because a working accounting system is an asset. Where a system cannot meet the requirement, we show why, and what connecting it instead of replacing it would involve.
What drives the cost of this work?
Fee follows assessment depth, not eventual project size. Drivers include the processes and departments in scope, the locations to visit, how closely existing systems and code must be examined, and the number of vendor proposals. A full PRD adds to it. Cost is confirmed after scoping. A single-question assessment is smaller than a full discovery.
What decides how long an assessment takes?
Mainly access to your people. Duration follows how quickly time can be arranged with the owner and function heads, how many locations are involved, and how readily data and contracts are shared. The number of vendors evaluated and the date of the decision meeting matter too, since a focused assessment runs shorter than a group-wide roadmap. A dated schedule follows scoping.
Will we get written documents, or just a meeting?
Written documents. Depending on the engagement, you receive the discovery report and process maps, the BRD and PRD, the architecture recommendation and the phased roadmap. The budget by phase, the risk register and a vendor scorecard come with them, and management sees the whole pack in a working session. Challenges are answered there.
Who owns the documents, and can we hand them to another vendor?
The client owns everything produced for it. Reports, requirement documents, architecture, roadmap and any diagrams or models can be edited, used internally or handed to any vendor. Nothing is licensed back and nothing is withheld. Code review findings and prototype code follow the same ownership terms, so they are yours too.
How do you protect our data and confidential information?
A signed confidentiality agreement is in place before the first discovery interview. It covers operational data, financials, customer lists and commercial terms, so nothing rests on a handshake. We ask for the minimum data needed and prefer masked or sample extracts, and documents sit behind restricted access limited to the people on the engagement. Vendor pricing stays private from rival vendors.
Do you stay involved afterwards, and what do you need from us to start?
Yes, if you want it. Options include a fractional CTO retainer, help with vendor selection, oversight of another vendor’s delivery, or a briefing for the internal team executing the plan. To start, we need four things. First comes access to your people. The rest are read access or sample exports from current systems, the real constraints on budget and timing, and one senior person who can settle disputes between departments.
When would you tell us not to hire a consultant at all?
When the decision is small enough to make alone. If the requirement is one form, one report or one integration and the expected cost is known, building it directly is the better use of budget. The same holds where a written requirement and a trusted vendor already exist, since reviewing that single proposal is enough. A report will not undo a choice already made.
Read before you decide.
Practical notes on the questions this service raises, not product marketing.
10 Signs Your Business Has Outgrown Excel
Ten concrete signs a spreadsheet has stopped being a safe way to run part of your business, and what to check before you decide to replace it.
How to Create a Technology Roadmap for Your Business
A practical method for building a technology roadmap that sequences investments by value, effort and dependency instead of by whoever asks loudest.
Is WhatsApp Becoming Your Unofficial Business Software?
How to tell when WhatsApp has quietly become your system of record for orders and approvals, and how to fix that without banning the app.
How Much Is Disconnected Software Costing Your Business?
No universal figure exists for what disconnected software costs. Build your own baseline from duplicate entry, errors and delayed decisions.
Let’s Build the Right Software for Your Business
Tell us about your current operational challenge, spreadsheet bottleneck, or software requirement. An experienced engineer will review your workflow and reply within one business day.
- No obligation consultation
- Senior engineer reviews your brief
- Your operational details stay 100% confidential
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirementsRelated Practices & Services
Custom Software and Product Engineering
When the assessment concludes that software should be built, this is the team that builds it to the requirement document you already own.
MVP and Product Development
For founders whose roadmap starts with a small first version put in front of real users before the full product is funded.
ERP and CRM Implementation
When the recommendation is a packaged product, properly configured and rolled out, rather than something built from scratch.
Software Maintenance, Support and Rescue
When due diligence finds an existing system worth stabilising and completing instead of replacing.