Use a OneGO product, or have us build — a practical split

The short answer

If the work is billing, a straightforward CRM pipeline, hostel operations, a conventional ERP, or internal task follow-up, start from the product we already implement. If the work is a process we have not productised — a marketplace, a specialist workflow, a first version of a new company product — we should build it as a project. Do not force a product to pretend it is a platform, and do not commission a custom system that duplicates a product we could have configured in weeks.

The problem we see

Owners arrive with a feature list copied from a SaaS homepage. The list is not the process. The process is: who captures the order, who checks stock, who raises a job, who collects payment. When we map that, it often matches BizBook or Work Ops closely enough to start there. Sometimes it matches nothing we sell. Both answers are useful. The expensive answer is pretending they are the same.

When a product is the honest fit

A product is honest when:

• the objects on screen are the objects in the business (invoice, enquiry, room, job, task)
• you can accept the product’s way of doing the 80% that is ordinary
• you want implementation and support, not a unique architecture

A custom build is honest when:

• the process is the product you sell
• two departments cannot agree on a shared template
• you are a startup whose first version should stay small and specific

Trade-offs

Products are faster to stand up and cheaper to keep in line. Custom work can follow an unusual process exactly, and it will cost more to change later if the process was never written down. We will not invent a return-on-investment figure for either. The decision is whether the software should look like a known job, or like your job.

Software development and startup product work are the custom paths. Products stay on the products hub. Mixing them in one quote without naming the split is how scopes drift.

How OneGO scopes it

We name the starting point in the quote: product implementation, custom build, or a short discovery if we cannot tell yet. Datalytx is an example of product-shaped work delivered as a real system for a named client — still not a promise that your analytics or operations will look the same.

What to do next

Send the process in a short note, not a feature list. We will say whether a OneGO product is the starting point or whether the work should be built. That sentence belongs in the quote, not in a later change request.