Software people ask us for
When does custom software make sense?
Most businesses should buy software, not build it. A subscription to a decent tool costs less than a month of engineering, and someone else fixes its bugs. We say so on a lot of first calls.
The trouble starts when the tool you bought only covers 70% of the job. Your team fills the other 30% with a spreadsheet, a shared inbox and somebody’s memory. That gap is where custom software earns its keep: the trade pricing rules nobody else handles the way you do, the returns process that touches three systems, the customer portal your account managers keep promising.
Three signs you’ve outgrown off-the-shelf
First, people copy data between tools by hand every day. Second, a process that makes you money only exists in one person’s head, so holidays become a risk. Third, you’ve already paid for two or three tools that each promised to fix it, and the spreadsheet is still open on every screen.
If none of that sounds familiar, keep buying. If it does, the cheapest next step is a two-week prototype that you can click through with the people who’ll use it, before anyone commits to a big number. Plenty of prototypes end with us telling a client to configure a tool they already own, or to connect two systems with workflow automation rather than write a new app.
What “custom” covers for us
For us it usually means one of four things: a customer or trade portal, an internal tool that replaces a spreadsheet, an API that partners can use instead of emailing CSV files, or a mobile app for people who work away from a desk. Almost all of them read and write data in an ERP or a store, which is why custom builds often sit next to ERP integration work.
Everything a first release needs
Every build ships with these eight things, so the software keeps running after hand-over.
Boring technology, done well
We pick proven tools your next developer will already know, and write the code they would want to inherit.
- Typed end to endTypeScript on the front and back, with a schema shared by both.
- Tested where it mattersBusiness rules covered by tests that run on every change.
- Versioned APIEvery endpoint documented with OpenAPI and versioned, so partners never break.
- Deploys in minutesContinuous deployment to staging, one click to production.
// GET /v1/orders?customer=:id -> trade customer order history export const listOrders = route({ method: "GET", path: "/v1/orders", auth: "customer", query: z.object({ cursor: z.string().optional(), limit: z.number().max(100).default(25) }), handler: async ({ user, query }) => { const rows = await erp.orders.list({ customerId: user.customerId, ...query }); return { data: rows.map(toPublicOrder), next: rows.cursor }; }, });
Works with
Who we build for, and who we’d send elsewhere
We’re a small senior team in Delhi working with businesses across time zones. That suits some projects very well and others not at all.
✓A good fit
×Probably not us
Your first release, week by week
- Week 0
Audit call
30 minutes on the job the software must do.
Problem brief - Weeks 1–2
Prototype
A discovery workshop, then a clickable prototype you can test.
Prototype link - Week 3
Quote
Fixed scope, price and dates for the first release.
Fixed quote - Weeks 4–10
Build
Weekly demos on staging, code in your repository.
Staging app - Release
Launch + run
Production launch, monitoring, then a support plan or hand-over.
Live release
What usually goes wrong with custom software projects
Custom builds fail in fairly predictable ways. Here are the four we plan for on every project, and what we do about each one.
Scope creeps until nothing ships
Every weekly demo sparks a good idea. Add them all and the first release slides from ten weeks to six months.
Every new idea goes on a “next release” list with a rough size next to it. You choose what swaps in, and the date only moves if you decide it should.
It works in the demo, then breaks on real data
A test customer has five orders. Your biggest account has 40,000, three ship-to addresses and a pricing rule from 2017.
We ask for an anonymised copy of real data in week one and build against it. The ugliest records become test cases.
Nobody uses it
Software that’s technically fine still fails if the warehouse team finds it slower than the spreadsheet it replaced.
The people who’ll use it every day test the prototype, as well as the person who signs the cheque. If they’d go back to the spreadsheet, we change the design before we write the backend.
You’re stuck with one supplier
Code in the agency’s account, in a framework only they use, with no docs. Changing supplier means starting again.
Your repo, your cloud, mainstream tools, written docs and a recorded walkthrough. Another team should be able to pick it up within a week.
What a normal build week looks like
You shouldn’t have to chase us for news. Here’s the rhythm during a build, and the time we’ll need from your side to keep it moving.
What you get each week
What we need from you
Terms you’ll hear in the first meeting
Software projects come with their own vocabulary. These are the words we use most, explained.
- Prototype weeks 1–2
- A clickable mock-up of the main screens. It looks real but has no backend, so it’s cheap to change. We use it to test the idea with real users before committing to the build.
- MVP first release
- The smallest version that does the job end to end for real users. People rely on it from the day it ships.
- Staging
- A private copy of the app where we show work in progress. Nothing there touches live customers or real orders.
- API
- A documented way for one system to ask another for data, like a portal asking the ERP for a customer’s invoices.
- Roles and permissions
- Rules about who can see and change what. A sales rep sees their accounts; finance sees everything.
- Technical debt
- Shortcuts that save time now and cost time later. Some is fine. We write down any we take, so you know where they are.
- CI/CD
- Automatic checks and deploys on every change, so releasing is a button press rather than an evening’s work.
About custom development
Anything else, ask on the audit call.
Ask an engineer
Not answered here? Ask on the free 30-minute audit call. An engineer replies within one business day.
Quick facts
- Based in Delhi, India Working across time zones, with written weekly updates.
- Fixed quote first Nothing is billed before you agree it.
- You own it The code, workflows and accounts are yours.
- Stores and ERPs Shopify, BigCommerce, WooCommerce and Adobe Commerce, with NetSuite, SAP Business One, Odoo and Dynamics 365.
Should we build or buy?
Buy when an off-the-shelf tool covers most of the job. Intelligize Digital recommends building only when your process is a real advantage, or the tools you tried force workarounds every day. The prototype answers the question cheaply.
Who owns the code?
You do. Intelligize Digital works in your repository and cloud accounts from the first commit, and nothing is licensed back to you.
Which technologies do you use?
Mostly React and Next.js on the front, Node or Laravel on the back, PostgreSQL for data, and React Native for mobile. We pick what your team can maintain.
Can you connect it to our ERP and store?
Yes. Intelligize Digital integrates custom software with NetSuite, SAP Business One, Odoo, Dynamics 365, Shopify and more, through their APIs or through a workflow engine workflows.
What happens after launch?
Either a monthly support plan with monitoring and small changes, or a clean hand-over with docs, tests and a recorded walkthrough for your developers.
How long does custom software take to build?
A clickable prototype takes about two weeks. A typical first release takes six to ten weeks after that, depending on how many systems it connects to and how many user roles it needs. We’d rather ship a smaller first release sooner and add to it.
Can you take over software another agency built?
Usually, yes. We start with a short code review to see what state it’s in, how it’s deployed and whether there are tests. Sometimes a partial rewrite is cheaper than patching, and we’ll say so with reasons.
Do we need our own developers?
No. Many clients don’t have any. We can run the software on a monthly support plan, or hand it to developers you hire later with docs and a recorded walkthrough.
How do you keep our data safe?
Data stays in your cloud accounts. We use role-based access, encrypted connections, secrets kept out of the code, and an audit log for sensitive actions. For portals, customers only ever see their own records.
Can we start with a prototype and stop there?
Yes. The prototype is a fixed-price piece of work. You keep it, along with the notes from user testing, and you’re under no obligation to build with us afterwards.
What does a custom quote depend on?
Mostly the number of screens and user roles, the number of systems it integrates with, how messy the existing data is, and whether it needs a mobile app. The discovery workshop turns those into a fixed scope and price.
What should your
software do?
Describe the job off-the-shelf tools get wrong. An engineer replies within one business day with how we would approach it.
What happens next
- An engineer replies Within one business day, by email.
- A free 30-minute audit On a call with an engineer.
- A fixed quote It follows the audit. Nothing is billed before you agree it.