Home / Request a quote
Ask for a quote, keep the scope either way
Describe the problem you need software to solve. You get a reply within one working day, a call with an engineer who would do the work, and a written scope covering approach, technology stack, phasing and cost. That document is yours whether or not you engage GegoSoft.
GegoSoft builds SaaS platforms and extends software it runs in production, for clients in India, the United States, Australia, Europe and Dubai. There is no separate sales team, so the person who prices the work is the person who would be accountable for delivering it.
What a GegoSoft quote is
- Cost
- No charge, and no obligation to proceed.
- First reply
- One working day, Monday to Friday, 10:00-18:30 IST (UTC+5:30)
- Prepared by
- The engineer who would lead the build, with the founder.
- Sequence
- Written enquiry, then a call in your time zone, then the written scope and estimate.
- You keep
- The scope document, including the assumptions behind the figure, whether or not the engagement proceeds.
- Accuracy
- Early figures are ranges. A phase is quoted flat only once its scope is written down and agreed.
- Legal entity
- GegoSoft Technologies (OPC) Private Limited, Madurai, Tamil Nadu, India. Established 2017.
Tell us what needs building
What to include
The more of this you can answer, the closer the first number will be to the last one.
- What the software has to do, described from the user's side rather than as a feature list.
- Who uses it, and roughly how many of them.
- Anything it replaces, or has to exchange data with.
- Where your users and your data sit, if either is regulated.
- Any date that is genuinely fixed, and what fixes it.
- Your time zone, so we propose a call at a reasonable hour.
Enquiry details are used to prepare your estimate. We do not add the address to a mailing list and we do not pass it on.
Three ways a quote gets to a number
A product that does not exist yet
Priced phase by phase after the scope call. The first phase is normally a working slice of the product rather than a document, so the estimate for later phases is written against something running.
Needed to quote: the problem, the users, the constraints that are real.
A change to software we already run
GegoK12, ChurchCMS, BloodBank.software, BOQ Manager, ChemTracker, eTenderz and Daybook are in production and extensible. Name the product and describe the gap you hit; the engineer who maintains it prices the change. Extending one of these is usually faster and cheaper than building the same capability from scratch. See the products.
Needed to quote: the product, the gap, how many users and sites.
A codebase somebody else wrote
We read the source before quoting the work. Takeover estimates price the review, the immediate fixes and the first planned phase separately, so you can stop after the review if the answer you get is not the one you wanted.
Needed to quote: repository access or a read-only copy, and what currently breaks.
How the estimate is produced
AI does the first pass. An engineer signs the number.
Our engineers use Claude Code every day, and we use it when sizing work too: reading a brief against comparable projects we have delivered, drafting a phase breakdown, and listing the assumptions that would move the figure. None of that reaches you unread.
The engineer who would lead the build reviews the draft line by line before it is sent, and the same boundary holds through delivery: AI writes a great deal of the code, humans choose the architecture, approve every merge and deploy to production. How we build with AI.
What the scope document contains
Approach. How the problem gets solved, and what we deliberately left out.
Stack. The technologies proposed, and why those rather than the alternatives.
Phases. What ships in each one, in an order that gives you something usable early.
Assumptions. The specific things that, if wrong, would change the cost.
Cost. A figure or range per phase, not one number for everything.
Ownership. Where the code, the data and the deployment sit at the end.
Questions before you send it
Does GegoSoft charge for a software development quote?
No. GegoSoft prepares a written scope covering approach, technology stack, phasing and cost at no charge, and the client keeps that document whether or not the engagement proceeds. There is no obligation attached to requesting one.
How long does it take to get a quote from GegoSoft?
An enquiry gets a first reply within one working day, Indian Standard Time. A scope call follows, and the written estimate comes after that call. How long the estimate itself takes depends on how much there is to read: a change to software GegoSoft already runs is quick, while a takeover of an existing codebase needs the source reviewed first.
What information is needed for an accurate software quote?
What the software has to do described from the user's side, who uses it and roughly how many, anything it replaces or must exchange data with, whether the users or the data fall under a regulatory regime, and any date that is genuinely fixed. A rough answer to each of these produces a closer estimate than a precise answer to one of them.
Who prepares the estimate?
The engineer who would lead the build, together with the founder. GegoSoft does not employ a separate sales team, so the first technical conversation and the figure both come from the people accountable for the delivery.
Can GegoSoft quote for a small change rather than a full project?
Yes. A single screen, a report, an integration or a change to one of GegoSoft's own products are all quoted the same way as a larger build, and small work is often the fastest route to a decision about a larger one.
Does the quoted figure change once work begins?
A phase is quoted flat only once its scope is written down, so within an agreed phase the figure holds. Where scope changes after the estimate, the change is re-priced in writing and agreed before the work is done rather than appearing on an invoice later.
Can GegoSoft quote on a codebase built by another team?
Yes, after reading the source. Takeover estimates separate the code review, the immediate fixes and the first planned phase so the client can act on the review alone and stop there if that is the sensible outcome.
Send the problem, not a specification
A half-formed description is enough to start. If you would rather see the shape of this work before asking for a number, the case studies set out what was built, what it cost in effort and what was deliberately left out.