Written assessment of what to build, buy or configure before budget is committed
Technology strategy and product consulting covers discovery, requirement documents, architecture advice, a phased roadmap and a costed budget. It is for owners and founders deciding whether to build, buy or configure. The documents are written so they can be handed to any vendor.
- Documents written to be used with GullySystem or any other vendor
- Findings delivered as written documents, with a working session to discuss them
- Confidentiality agreed in writing before discovery begins
This work is used by manufacturers deciding whether to extend a licensed ERP or replace a plant spreadsheet. It is used by distributors comparing a packaged product with software built around their trade schemes. Clinics and schools with software bought department by department use it too, as do founders holding a quotation they cannot judge. Some engagements end with a build plan. Others conclude that a licence and a short configuration exercise is the better route, or that a half-finished project can be completed rather than restarted.
Where Technology Decisions Are Taken Without Enough Information
Quotations That Cannot Be Compared
Two or three vendors quote for the same brief, but each defines the scope differently. There is nothing to compare line by line. The decision falls back on price or presentation, and the gaps appear later as change requests.
Different Scope Assumed by Each Department
The requirement exists as meeting notes, a chat thread and one person’s memory. Accounts assumes a credit check is included, a branch assumes stock is, and the vendor has quoted for neither. Without a signed document, each gap becomes a paid change request.
An Earlier Purchase With No Recorded Cause
A previous investment did not deliver what was expected, and the reason was never written down. A new proposal is now prepared on the same assumptions. Whether the fault lay in the product, the scope or the rollout is still unknown.
No One Inside to Judge the Proposal
There is no technology head, so the decision waits for an owner who is not technical. A vendor’s pre-sales engineer often becomes the informal advisor. Their recommendation reflects what their employer sells.
A Single Figure Without a Breakdown
The proposal gives one amount and one duration. It does not show what is excluded, which requirement drives the cost, or what licences and support 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 that is described as nearly ready. Nobody on the client side has opened the code, the database or the server. Continuing, changing vendors, finishing internally or stopping cannot be decided on evidence.
Replacement Decisions Deferred Each Year
Spreadsheets are expected to be replaced eventually, and the decision moves to the next year. Nobody has documented what replacement involves or what it costs. Postponing is still a decision, with no figure set against either side.
These are not technology problems yet. They are decisions taken with incomplete information. Structured assessment work has a defined scope and fee. A wrong decision carries the cost of the development that follows it.
A Written Plan for Approval, Challenge or Handover to Any Vendor
The work starts with the business rather than with a technology proposal. We meet the staff doing the work and review the systems, contracts and figures already in place. The result is a written assessment covering the actual problem, what it costs in the client’s own figures, what solving it involves, and whether to build, buy, configure or wait.
The Problem Before the Product
No platform is named until the situation is understood. We map how work moves today, where it stalls and who re-enters what. The step worth funding is sometimes not the one that prompted the enquiry.
Build, Buy or Configure Compared Both Ways
Each recommendation comes with the case against it. Options are compared on licences over three years, migration, training, internal staff time and how far the business would have to change to fit a packaged product.
A Phased Plan Sized to the Budget
The roadmap is phased so the first phase is small enough to fund and test. Each phase lists its scope, dependencies and cost drivers. A decision gate follows each one, 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
One document states scope, user roles, screens and system boundaries, so each vendor prices the same thing. Their figures can then be compared.
A Recorded Build, Buy or Configure Recommendation
The recommendation carries its reasoning and trade-offs in writing. It can be presented to partners, a board or a bank.
A Roadmap With Stop Points
Work is sequenced so the phase addressing the largest pain comes first. A defined gate at the end of each phase records whether the next is still worth funding.
A Budget Showing Its Drivers
The estimate is broken down by phase and shows what drives each part. When a total is larger than planned, the requirement to reduce is visible. Cost figures are confirmed after scoping.
Risks Recorded With Owners
Migration gaps, staff adoption, statutory dates, vendor dependency and reliance on one person are listed. Each risk has an owner assigned.
Documents That Belong to the Client
The requirement, architecture and roadmap belong to the client. They are written for handover to any vendor. The plan does not assume GullySystem does the build.
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. The aim is to document how the business runs, not how the manual describes it.
Business Requirement Document (BRD)
The business case, objectives, processes in scope, departments affected, statutory obligations and success criteria. It is written in language a management team can approve.
Product Requirement Document (PRD) and Functional Specification
Features, user roles, permissions, screens, states, data fields, rules and deliberate exclusions. It is detailed enough for a developer to build from and for a client to review against.
Build, Buy or Configure Assessment
A costed comparison of custom software, a licensed package, configuring something already owned, or continuing manually for now. Each is checked against current processes, licence and subscription spend, and a three-year cost view.
Solution Architecture Advisory
The recommended shape of the system: modules, data model outline, integration points, hosting approach, access control and growth path. Alternatives and their trade-offs are stated.
Technology Stack Selection
A recommendation on languages, frameworks, database and hosting. It is judged on suitability, running cost and how easily staff can be hired or vendors changed later.
Software Vendor and Proposal Evaluation
Proposals are restated on a common scope. The client receives a scorecard against its 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. It covers what works, repository condition, data integrity, security exposure, dependence on individuals and what completion involves.
Automation Opportunity Assessment
A ranked list of processes to automate first. Each entry records the manual effort, the systems involved and the difficulty, so the automation budget follows the list.
AI and Cloud Readiness Assessment
A view of whether data, volumes and processes can support AI features or a cloud move yet. It lists what would need fixing first and which proposed use cases are worth pursuing.
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 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 stays for now and what is retired, and how the business keeps running through each 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 runs accounts in a licensed ERP, while production planning, job cards and rejections sit in spreadsheets. One vendor proposes a new MES and the ERP partner says the modules already exist. Discovery establishes which shop-floor steps the licensed modules cover, which need building, and what operators can enter during a shift. The outcome may be a small job-card layer feeding the existing ERP.
Distributor Holding Two ERP Proposals
A regional distributor has two proposals with a wide gap between them. Both are restated on one scope and tested against how the business trades, including slabs, schemes, credit limits, damaged-goods returns and sub-dealer pricing. Each is costed over three years, with migration, training and changeover time included. The output is a scorecard, a list of exclusions and questions for each vendor.
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. Parents are asked for the same details in each portal. The assessment identifies which system holds the master student record, which products stay and which are replaced. The order avoids the admission season and the fee cycle.
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 can be recovered and what completion requires. Management receives three options costed side by side, with a recommendation for the board.
Professional Firm Planning AI Document Review
An audit and advisory firm wants AI to handle document review. A readiness assessment finds that the source documents are scanned images filed by client name without consistent structure. Digitising and indexing therefore come first. The roadmap places that in Phase 1 and AI review in Phase 2.
Founder Defining a First Version
A founder has a feature list drawn from conversations with three prospective customers, and a plan to build all of it before launch. Discovery separates what tests demand from what can wait. It produces a PRD for the smaller first version and prices the phases. Some engagements recommend running the service manually 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 significant sum to an ERP, a platform or a custom build. They want the decision examined by someone who is not selling the product being decided.
Companies Whose Last System Was Not Adopted
Organisations that bought software the staff work around. They want the reason established before spending on a replacement that could fail the same way.
Businesses Without an Internal Technology Lead
Companies where the owner, finance head or operations manager evaluates vendors, architectures and contracts alongside their own role. There is no technical peer to check the answers.
Founders Planning a Product
People planning a SaaS product, marketplace or app. They need the idea reduced to a defined first version, a requirement document and a phased budget before development money is committed.
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. This applies before renewing, acquiring or escalating.
When This Service Is Not Needed
If the requirement is small and already 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, a review of that proposal is enough. A report will not change a decision already taken on other grounds. This is stated on the first call.
Enterprise Capabilities in Plain Business Terms
Process Mapping From Observation
Current-state maps are drawn from watching the work and speaking to the people doing it. The process document is treated as a reference only.
Cost of the Current Way
Manual effort, rework and delay in each process are estimated from the client’s own volumes and staff costs. The business case rests on those figures.
Requirement Prioritisation
Each requirement is classed as essential, valuable or deferrable. The trade-off is stated, so the first phase stays within budget.
User Role and Permission Modelling
Who sees what, who approves what and who can override. This is defined early because it shapes the design and most later disagreements.
System Boundary Definition
A defined line around what the new system does and what stays with existing tools. Scope creep usually starts at this line.
Three-Year Cost of Ownership
Licences, hosting, migration, training, support and internal effort are compared across options. The years after the quoted one are included.
Architecture Options With Trade-offs
Two or three viable designs, each showing its cost, what it constrains and what it makes easier later. A single answer is not presented as the only one.
Data Migration Feasibility Review
A review of existing records for duplicates, missing fields and inconsistent codes. It shows what can move, what needs cleaning and what is left behind.
Vendor Proposal Normalisation
Competing quotations are restated on identical scope and assumptions. Each vendor’s exclusions are listed.
Code and Repository Review
For due diligence, this covers repository history, structure, test coverage, dependency risk and documentation. It shows whether existing work can be built on.
Security and Data-Handling Review
Where personal, financial and customer data sits today and who can reach it. It also lists what the proposed design needs in order to handle that data responsibly.
Phasing and Dependency Sequencing
Work is ordered so each phase is usable on its own. Statutory dates and business seasons are built into the sequence.
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 who do the daily work. The aim is to establish what the business is trying to achieve and what obstructs it. From the client we need an hour with each person, freedom for them to speak plainly, and one senior person who can settle disagreements between departments.
- 02
Current-State and Cost Review
We map the processes in scope, examine the systems already run and review what technology currently costs. From the client we need read access or sample exports, copies of licence and vendor agreements, and last year’s technology spend, including AMCs and subscriptions.
- 03
Options and Build-Buy Assessment
We identify the realistic options, test packaged products against the actual process and cost each route over three years. From the client we need the real constraints: the budget ceiling, what cannot change, and any season, audit or statutory date 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. From the client we need review time from each function head and a written sign-off. Every later cost and timeline is measured against this document.
- 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. From the client we need a view on phasing and on how much internal capacity the team can give the project.
- 06
Decision Support and Handover
We present the findings to management, respond to challenges and hand over every document. From the client we need a decision meeting with the people who can approve. If the client then goes 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
- Tally Prime / ERP 9
- Zoho Books and Zoho One
- Odoo
- SAP Business One
- Microsoft Dynamics 365
- Industry-specific Indian 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
- GST e-invoicing and e-way bill
- DPDP Act obligations for personal data
- TDS and payroll statutory 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 concluded in favour of custom software would have no value.
Each Recommendation Carries Its Counter-Argument
The reasons against the preferred option are written by us and included. A plan tested against its own weaknesses is easier to review than one that only 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 counted. These items often change which option is the less expensive.
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 belong to the client and are written for any vendor. The client may run a tender, hand the plan to an existing partner, or use an internal team.
Advice From a Team That Also Delivers
The team also builds, integrates and supports systems as well as planning them. Estimates, risks and sequencing draw on delivery work rather than 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. It includes a short written recommendation and a working session.
Full Discovery and Roadmap
End-to-end discovery, requirement documents, architecture, phased roadmap, budget and risk register. The pack is delivered for a board or partners to review and sign off.
Technical Due Diligence
An independent review of what exists, what works and what completion or repair involves. It also considers whether the current arrangement should continue.
Fractional CTO Retainer
Ongoing advisory for companies not ready to hire. It covers vendor work review, architecture decisions, negotiations and keeping the roadmap current.
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?
The weight of the decision matters, not the size of the company. A structured assessment suits a sum that would be painful to lose, or a system the business will run on for years. It is not needed when the requirement is small and well understood. In that case the budget is better spent on building, and this is said 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. Realistic options are then tested against those findings and written up. Findings are discussed as they emerge, so the final presentation holds no surprises.
Can you advise us without taking the development project?
Yes. Consulting is a standalone engagement with its own fee and deliverables. The documents are written so any competent vendor can build from them. We can help run a tender in which GullySystem does not take part. A later build by us would be a separate decision and a separate agreement.
Can you evaluate quotations, vendors or a shortlist we already have?
Yes. We restate each proposal on a common scope so the prices can be compared, and list what each vendor has excluded. The product or approach is checked against how the business works. The client receives a scorecard and the questions to put to each vendor before signing. Where a proposal looks reasonable, we say so.
Can you assess a project that is half-built or has stalled?
Yes. We review what exists rather than what was promised. That covers working software, the repository and its history, the database, data quality, documentation and dependence on one person. The result is a statement of what is usable, what completion involves, and whether to continue, move the work or stop. This applies whether or not the repair work comes 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. A working Tally installation, billing package or branch system that staff know is an asset. Where a system cannot support the requirement, we show why and what connecting it instead of replacing it would involve.
What drives the cost of this work?
The fee follows the depth of the assessment rather than the size of the eventual project. Drivers include the processes and departments in scope, the locations to visit, and whether existing systems and code need detailed examination. The vendor proposals to evaluate, a full PRD or a business-level requirement, and any ongoing advisory also count. Cost is confirmed after a first conversation and scoping. A focused single-question assessment is smaller than a full discovery.
What decides how long an assessment takes?
Mainly access to the client’s 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. It also follows the number of options and vendors evaluated, the time the team needs to review drafts, and whether a decision meeting can be convened. A focused assessment is shorter than a group-wide roadmap. A dated schedule is confirmed after scoping.
Will we get written documents, or just a meeting?
Written documents. Depending on the engagement, these include the discovery report and process maps, the BRD and PRD, the architecture recommendation and the phased roadmap. The budget by phase with its drivers, the risk register and a vendor scorecard are also included. The pack is presented to management in a working session, where challenges are answered.
Who owns the documents, and can we hand them to another vendor?
The client owns everything produced for it. The 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. Source code review or prototype code, where included, is handed over on the same terms.
How do you protect our data and confidential information?
Confidentiality is agreed in writing before discovery begins. It covers operational data, financials, customer lists and commercial terms. We ask for the minimum data needed and prefer masked or sample extracts where full records are not required. Documents are shared through restricted access, and access is limited to the people on the engagement. Vendor proposals and pricing shared with us are not discussed with the vendors concerned.
Do you stay involved afterwards, and what do you need from us to start?
Yes, if the client wants 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. The first is access to the people who do the work. The others are read access or sample exports from current systems, the real constraints on budget and timing, and one senior person who can settle disagreements between departments.
When would you tell us not to hire a consultant at all?
When the decision is small enough to make without one. 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 applies where a written requirement and a trusted vendor already exist. In that case a review of the one proposal is enough. A report will not reverse a choice already made on instinct or relationships.
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?
There's no universal figure for what disconnected software costs. Here's how to build your own baseline from duplicate entry, errors and delay.
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.