Decide What to Build, Buy or Leave Alone Before You Commit the Budget
GullySystem’s technology strategy and product consulting helps Indian business owners and founders decide what to build, buy or fix. You get a written requirement document, an architecture recommendation, a phased roadmap and a budget your management can approve.
- Advice you can act on with us or with any other vendor
- Written documents, not a verbal opinion in a meeting
- NDA signed before discovery begins
We do this work for manufacturers deciding whether to extend an ERP they already licence or replace a plant spreadsheet, distributors weighing a packaged product against something built around their trade schemes, clinics and schools whose software was bought department by department over the years, and founders holding a quotation they have no way to judge. Some engagements end with a build plan. Some end with us telling you the cheaper answer is a licence and a short configuration exercise, or that the half-finished project you have already paid for can be completed rather than started again.
Is a Technology Decision Sitting on Your Desk With Nobody to Judge It?
Three Quotations You Have No Way to Compare
One vendor quotes a small figure, another quotes several times more, and both say they understood the same brief. Because each proposal defines the scope differently, there is nothing to compare line to line. The decision gets made on price or on who was more convincing, and the difference reappears six months later as change requests you had not budgeted for.
Each Department Has Agreed to a Different Scope
The requirement exists as meeting notes, a WhatsApp thread and one person’s understanding of what was discussed. Accounts assumes the credit check is included, the branch head assumes stock is, and the vendor has quoted for neither. Because nothing was written that all three signed, every gap becomes a paid change request and an argument about who agreed to what.
Nobody Has Established Why the Last Purchase Failed
An earlier investment did not deliver what was expected, and the reason was never written down. Now a fresh proposal sits on the table, prepared on the same assumptions and judged by the same people who judged the last one. Without knowing whether the fault was the product, the scope or the rollout, you are being asked to bet again on the same reasoning.
Nobody Inside the Company Can Say Yes or No
There is no technology head, so the decision waits for an owner who is not technical and does not want to guess. In the meantime the most persuasive vendor’s pre-sales engineer becomes your de facto advisor, and their recommendation is shaped by what they sell.
A Single Figure With Nothing Behind It
The proposal states one amount and a duration, with no breakdown of what drives either. You cannot tell what has been excluded, which requirement is making it expensive, what would bring it down, or what the second and third years cost in licences and support. Signing means committing cash against a number you have no way to question.
You Cannot Check What You Have Already Paid For
Instalments have gone out for months against a demo that never quite becomes usable, and every update says it is nearly ready. Nobody on your side can open the code, the database or the server to see what genuinely exists, so the choice between continuing, changing hands, finishing it internally or writing it off cannot be made on evidence. Each month without that answer is another payment.
The Replacement Decision Gets Deferred Every Year
Everyone agrees the spreadsheets will have to go eventually, and the decision has been pushed to next year for three years running, because nobody has established what replacing them would involve or what it would cost. Postponing feels like the safe option. It is still a decision, taken annually, with no figure put against either side of it.
None of these are technology problems yet. They are decisions being taken without enough information. A decision examined properly costs a bounded piece of structured work; a decision taken badly costs a year of development and the money that went with it.
A Written Plan You Can Approve, Argue With, or Take to Any Vendor
We start with your business, not with a technology proposal. We sit with the people who actually do the work, look at the systems, contracts and numbers you already have, and produce a written assessment: what the real problem is, what it is costing you in your own figures, what it should take to solve, and whether the answer is to build, buy, configure or leave things alone for now.
The Problem Before the Product
No platform is named until the situation is understood. We map how work moves today, where it stalls, who re-enters what, and which of those steps is actually worth spending money on — which is often not the one that prompted the enquiry.
Build, Buy or Configure, Argued Both Ways
You get a recommendation and the honest case against it. Options are compared on the full picture: licences over three years, migration, training, internal staff time, and how much of your way of working you would have to give up to fit a packaged product.
A Plan That Survives Your Budget
The roadmap is phased so the first phase is small enough to fund and prove. Each phase has its scope, its dependencies, what drives its cost, and a decision gate where you can continue, pause or stop without wasting what came before.
What You Hold at the End of the Engagement
Focus on business value before discussing technology. Here is what your team accomplishes in week one.
A Requirement Anyone Can Quote Against
One document that states scope, user roles, screens and system boundaries, so three vendors price the same thing and their numbers can finally be compared.
Build, Buy or Configure, Settled
A recommendation with the reasoning and the trade-offs written down, so the choice can be defended to partners, a board or a bank instead of resting on one person’s instinct.
A Roadmap With Stop Points
Work sequenced so the phase that relieves the most pain comes first, with a defined gate at the end of each phase where you decide whether the next one is still worth funding.
A Budget With Its Drivers Exposed
An estimate broken down by phase, showing what makes each part expensive, so you can see exactly which requirement to drop when the number is larger than you expected.
Risks Written Down Before They Arrive
Migration gaps, staff adoption, statutory deadlines, vendor dependency and single-person knowledge listed with an owner against each, rather than discovered during go-live week.
Documents You Can Take Anywhere
The requirement, architecture and roadmap belong to you and are written to be handed to any vendor. The plan does not depend on us being the ones who build it.
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 the live data, to document how the business actually runs rather than how the manual says it does.
Business Requirement Document (BRD)
The business case, objectives, processes in scope, departments affected, statutory obligations and success criteria, written in language your management team can approve without a translator.
Product Requirement Document (PRD) and Functional Specification
Features, user roles, permissions, screens, states, data fields, rules and what is deliberately excluded — the level of detail a developer can build from and a client can hold them to.
Build, Buy or Configure Assessment
A costed comparison of building custom software, licensing a packaged product, configuring something you already own, or continuing manually for now, evaluated against your processes 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 how it should grow, with the alternatives and their trade-offs stated.
Technology Stack Selection
A recommendation on languages, frameworks, database and hosting judged on suitability, running cost, and how easily you can hire or change vendors later — not on what is currently fashionable.
Software Vendor and Proposal Evaluation
Proposals rewritten onto a common scope so they can be compared, a scorecard against your criteria, the questions to put to each vendor, and the gaps in what they have quoted.
Technical Due Diligence
An independent review of an existing or half-built system: what actually works, code and repository condition, data integrity, security exposure, dependency on individuals, and what completing it would involve.
Automation Opportunity Assessment
A ranked list of the processes worth automating first, each with the manual effort behind it, the systems involved and the difficulty, so the automation budget goes where it returns most.
AI and Cloud Readiness Assessment
An honest view of whether your data, volumes and processes can support AI features or a cloud move yet, what would have to be fixed first, and which of the proposed use cases are worth pursuing.
Technology Cost Review
A look at what you currently spend on licences, subscriptions, hosting, AMCs and vendor retainers, including what is duplicated, unused or renewing automatically without anyone checking.
Fractional CTO and Ongoing Advisory
A technology head available a few days a month to review vendor work, approve architecture decisions, sit in on negotiations and keep the roadmap honest, for companies not ready to hire full time.
Legacy Modernisation and Digital Roadmap
A multi-year sequence for replacing or wrapping ageing systems: what moves first, what stays for now, what gets retired, and how the business keeps running through each step.
Where a Planning Engagement Earns Its Fee
Real-world business processes we configure and automate.
Manufacturer: Extend the ERP, or Replace the Plant Spreadsheet
A components manufacturer runs accounts in a licensed ERP while production planning, job cards and rejections live in spreadsheets on the shop floor. Two vendors propose a new MES; the ERP partner says the modules already exist. Discovery establishes which of the shop-floor steps the licensed modules genuinely cover, which need building, and what the operators can realistically be asked to enter during a shift — so the recommendation is a small custom job-card layer feeding the existing ERP, not a second system to reconcile.
Distributor: Two ERP Proposals, Neither Comparable
A regional distributor holds two proposals with a wide gap between them and no way to judge either. We rewrite both onto one scope, test each product against how the business actually trades — slabs, schemes, credit limits, damaged-goods returns, sub-dealer pricing — and cost both over three years including migration, training and the staff time lost during changeover. The output is a scorecard, a list of what each vendor left out, and the questions to ask before signing.
School Group: Software Bought Department by Department
A group of schools runs admissions on one product, fees on another and transport on a third, with parents complaining that each portal asks for the same details. An assessment establishes which system holds the master student record, which product is worth keeping, what has to be replaced, and in what order — sequenced so nothing changes during admission season or the fee cycle.
Logistics Operator: Keep Paying, Change Hands or Stop
A transport operator has to decide whether to release the next instalment on a driver and consignment app it has been funding for months. Technical due diligence establishes what code exists, whether the data can be recovered, how much of it is worth keeping and what completing it would actually require. Management receives the three options costed side by side and a recommendation it can put to the board.
Professional Firm: An AI Plan That Has to Wait Its Turn
An audit and advisory firm wants document review handled by AI after a partner sees it demonstrated. A readiness assessment finds the source documents are scanned images filed by client name with no consistent structure, so the first useful step is digitising and indexing them. The roadmap puts that in Phase 1 and the AI review in Phase 2, once there is something for it to read.
Founder: Deciding What Not to Build First
A founder arrives with a feature list built from talking to three prospective customers and a plan to build all of it before launch. Discovery separates what proves demand from what can wait, produces a PRD for the smaller first version, and prices the phases. In some engagements the recommendation is to run the service manually for a few months first and build only once the demand is real.
Is This Service Right for Your Business?
We partner with established businesses that have outgrown manual processes and want reliable systems.
Owners Facing Their Largest Technology Spend
Businesses about to commit a serious sum to an ERP, a platform or a custom build, who want the decision examined by someone who is not selling the thing being decided.
Companies Whose Last System Did Not Stick
Organisations that have already bought software the staff work around, and who want the reason established before spending on a replacement that could fail the same way.
Businesses With No Internal Technology Leader
Companies where the owner, the finance head or an operations manager is evaluating vendors, architectures and contracts alongside their own job, without a technical peer to check the answers.
Founders Planning a Product
People planning a SaaS product, marketplace or app who 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 before renewing, acquiring or escalating.
When You Should Not Buy This
If the requirement is small and already clear — one reminder flow, one report, one form — skip the consulting and spend the money on building it. If you already have a written requirement and a vendor you trust, ask us to review the proposal rather than run a full discovery. And if the decision has already been taken emotionally, a report will not change it, so keep the fee. We would rather say this on the first call than sell an engagement that adds nothing.
Enterprise Capabilities in Plain Business Terms
Process Mapping From Observation
Current-state maps drawn from watching the work happen and talking to the people doing it, not from the process document nobody has updated.
Cost of the Current Way
The manual effort, rework and delay in each process quantified using your own volumes and staff costs, so the business case rests on your numbers rather than ours.
Requirement Prioritisation
Every requirement classified as essential, valuable or deferrable, with the trade-off made explicit so the first phase stays fundable.
User Role and Permission Modelling
Who sees what, who approves what and who can override, defined early because it decides both the design and most of the arguments later.
System Boundary Definition
A clear line around what the new system does and what stays with your existing tools, which is where scope creep usually starts.
Three-Year Cost of Ownership
Licences, hosting, migration, training, support and internal effort compared across options, including the years after the one being quoted.
Architecture Options With Trade-offs
Two or three viable designs, each with what it costs, what it constrains and what it makes easy later, rather than a single answer presented as the only one.
Data Migration Feasibility Review
A look at your existing records — duplicates, missing fields, inconsistent codes — to establish what can actually move and what has to be cleaned or left behind.
Vendor Proposal Normalisation
Competing quotations restated on identical scope and assumptions so the comparison is genuine, with each vendor’s exclusions listed.
Code and Repository Review
For due diligence: repository history, structure, test coverage, dependency risk and documentation, to judge whether existing work can be built on.
Security and Data-Handling Review
Where personal, financial and customer data sits today, who can reach it, and what the proposed design would need to handle it responsibly.
Phasing and Dependency Sequencing
Work ordered so each phase is usable on its own and does not wait on the next, with statutory dates and business seasons respected.
Our Structured 6-Step Delivery Process
A transparent path from your first conversation to a reliable production release.
Business Discovery
We interview the owner, the function heads and the people who do the daily work, and establish what the business is trying to achieve and what is getting in the way. From you we need an hour each with those people, the freedom for them to speak plainly, and one senior person who can settle a disagreement between departments.
Current-State and Cost Review
We map the processes in scope, examine the systems you already run and look at what technology currently costs you. From you we need read access or sample exports from existing systems, copies of licence and vendor agreements, and last year’s technology spend, including AMCs and subscriptions.
Options and Build-Buy Assessment
We identify the realistic options, test packaged products against your actual process, and cost each route over three years. From you we need your real constraints: the budget ceiling, the things that cannot change, and any season, audit or statutory date the plan must work around.
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 you we need review time from each function head and a written sign-off, because this document is what every later cost and timeline is measured against.
Architecture, Roadmap and Budget
We produce the recommended architecture, the phased roadmap with its decision gates, the budget by phase with its cost drivers, and the risk register. From you we need an honest view of your appetite for phasing and how much internal capacity your team can give to the project.
Decision Support and Handover
We present the findings to your management, answer the challenges, and hand over every document. From you we need a decision meeting with the people who can approve. If you then go to market, we help you brief vendors and compare what comes back — whether or not we are 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
Why Business Owners Choose GullySystem
We Will Tell You Not to Build
A recommendation to license a product, configure what you already own, or wait another quarter is a legitimate outcome of this work. If we only ever concluded that you need custom software, the assessment would be worth nothing.
Every Recommendation Carries Its Counter-Argument
You receive the reasons against the option we prefer, written by us. A plan that survives your own scrutiny is far more useful than one that only sounds convincing in the presentation.
Costs Include the Ones Proposals Leave Out
Migration, training, the staff hours lost during changeover, licence renewals and the second and third year of support are counted. Those are usually what makes the cheap option the expensive one.
Written for Your Management, Not for Developers
The main documents are in plain business English so an owner, a partner or a finance head can read and challenge them, with the technical detail in an annexe for whoever builds it.
The Consulting Is Not a Hook for the Build
The documents are yours and are written for any vendor to work from. You are free to run a tender, hand the plan to your existing partner, or execute it with an internal team.
Advice From People Who Also Deliver
We build, integrate and support systems as well as plan them. Estimates, risks and sequencing come from having done the delivery work, not from a template applied to your industry.
Flexible Engagement Options
Choose an engagement model that matches your operational scope, budget, and timeline.
Focused Assessment
For a single bounded question — build or buy, this ERP or that one, is this proposal reasonable — with a short written recommendation and a working session to discuss it.
Full Discovery and Roadmap
End-to-end discovery, requirement documents, architecture, phased roadmap, budget and risk register, delivered as a pack your board or partners can sign off.
Technical Due Diligence
An independent review of what exists, what works, what it would cost to complete or repair, and whether the current arrangement should continue.
Fractional CTO Retainer
Ongoing advisory for companies not ready to hire: reviewing vendor work, approving architecture decisions, sitting in on negotiations and keeping the roadmap current.
Frequently Asked Questions
Straightforward answers to the questions owners ask before getting started.
Is a consulting engagement worth paying for if we are a small business?
It depends on the size of the decision, not the size of the company. If you are about to commit a sum that would hurt to lose, or choosing a system your business will run on for the next five years, a structured assessment is cheap insurance against the wrong choice. If the requirement is small and already well understood, it is not worth it — put the money into building the thing and we will say so on the first call.
What actually happens during the engagement?
Interviews, observation and documents. We speak to the owner, the function heads and the staff who do the work; we watch how a job actually moves from enquiry to payment; we look at your live data, your existing systems and your current technology spend. Then we test the realistic options against what we found and write it up. You are not left waiting until the end — findings are discussed as they emerge, so the final presentation contains no surprises.
Can you advise us without taking the development project?
Yes, and it is a common way to work with us. Consulting is a standalone engagement with its own fee and deliverables. The documents are written so any competent vendor can build from them, and we are happy to help you run a tender in which we do not participate. If you do want us to build it afterwards, that is a separate decision and a separate agreement.
Can you evaluate quotations, vendors or a shortlist we already have?
Yes. This is one of the shortest and most useful engagements we run. We restate each proposal on a common scope so the prices are genuinely comparable, list what each vendor has excluded, check the product or approach against how your business actually works, and give you a scorecard plus the specific questions to put to each vendor before you sign. 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: the working software, the repository and its history, the database and data quality, the documentation, and how dependent everything is on one person. You get a plain statement of what is usable, what completing it would involve, and a recommendation on whether to continue with the current vendor, move the work, or stop. We do this whether or not the eventual 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. If Tally, your billing package or a branch system works and your staff know it, that is an asset, not a problem. Where a system genuinely cannot support what you need, we show you why rather than asserting it, including what it would take to connect it instead of replacing it.
What drives the cost of this work?
The fee follows the depth of the assessment, not the size of the eventual project. The main drivers are how many processes and departments are in scope, how many locations we need to visit or interview, whether existing systems and code have to be examined in detail, how many options and vendor proposals must be evaluated, whether a full PRD is needed or only a business-level requirement, and whether you want ongoing advisory after the report. We scope and price it after a first conversation, and a focused single-question assessment costs a fraction of a full discovery.
What decides how long an assessment takes?
Access to your people, mostly. The duration is driven by how quickly we can get time with the owner and function heads, how many locations are involved, how readily existing data and contracts are made available, how many options and vendors have to be evaluated, how long your team needs to review the draft documents, and whether a decision meeting can be convened without waiting weeks for diaries. A focused assessment on one question is far shorter than a group-wide roadmap, and we give you a schedule tied to those inputs before starting.
Will we get written documents, or just a meeting?
Written documents, always. Depending on the engagement you receive the discovery report and process maps, the BRD and PRD, the architecture recommendation, the phased roadmap, the budget by phase with its drivers, the risk register and a vendor scorecard. We also present the pack to your management in a working session and answer the challenges, because a document nobody has argued with rarely gets acted on.
Who owns the documents, and can we hand them to another vendor?
You own everything we produce for you, in full. The reports, requirement documents, architecture, roadmap and any diagrams or models are yours to use, edit, publish internally or hand to any vendor you choose. Nothing is licensed back to you and nothing is withheld to keep you dependent on us. Where the engagement includes source code review or prototype code, that is handed over on the same terms.
How do you protect our data and confidential information?
We sign a non-disclosure agreement before discovery begins, covering your operational data, financials, customer lists and commercial terms. During the assessment we ask for the minimum data needed and prefer masked or sample extracts where full records are not necessary. Documents are shared through restricted access rather than open links, access is limited to the people on your engagement, and vendor proposals and pricing you share with us are never discussed with the vendors concerned.
Do you stay involved afterwards, and what do you need from us to start?
We can, in whatever form suits you: a fractional CTO retainer, help running a vendor selection, oversight of another vendor’s delivery, or a briefing session for the internal team who will execute the plan. To start, we need four things from you — access to the people who do the work and permission for them to speak candidly, read access or sample exports from your current systems, your real constraints on budget and timing, and one senior person empowered to decide when two departments want different things. That last one matters most, because these are business decisions before they are technical ones.
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
Discuss Your Requirement
Fill out this brief form and we’ll get back to you within one working day.
Related 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.