03 Stack
What we build on, and why it matters who maintains it
Chosen for the problem and for whoever will maintain it after we are gone, which rules out anything fashionable that nobody in your city can hire for.
Back end
- PHP 8
- Node.js
- Python
- REST APIs
Data
- PostgreSQL
- MySQL
- Redis
- S3-compatible storage
Front end
- React
- Next.js
- Vanilla JS
- Progressive web app
Delivery
- Git
- CI pipeline
- Staging
- Monitoring
- Backups
The maintainability test
04 Delivery
Working software every two weeks
The only reliable signal that a software project is on track is software that runs. Percentage-complete reports are not evidence, and by the time they are wrong it is too late.
Step 1: Agree the cycle
Each two-week cycle opens with exactly what is being built, drawn from the discovery backlog and prioritised by you rather than by us.
Day 1Step 2: Build and test
Automated tests on the core paths as the code is written, because a test suite added at the end is a test suite that documents the bugs rather than preventing them.
Days 2 to 9Step 3: Deploy to staging
Everything built in the cycle runs on a URL you can open, with real data shapes rather than placeholders.
Day 9Step 4: Review with the actual users
Not with a sponsor. The people who will use it, doing something real with it, which is where most requirement changes originate and should.
Day 10Step 5: Re-prioritise in the open
A new request is either swapped for something of similar size or added with a visible cost and date impact. Nothing is quietly absorbed and nothing is quietly dropped.
Day 10
The two-week rhythm is what made it work. We changed our minds about the approvals module in week six, when it was a conversation rather than a rebuild.
05 Handover
What a real handover contains
The code is the easy part. A handover is judged the first time something breaks at nine on a Monday and you are the one holding it.
- The repository, in your name, with the full history rather than a single squashed commit at the end.
- An architecture note explaining what talks to what and why, in language a new developer can read in an hour.
- The data model with the constraints and the reasoning, since this is the part that is expensive to change later.
- An API reference for anything another system consumes, including the error responses, which are always the undocumented half.
- A deployment and recovery runbook, and a restore that has actually been tested by restoring, not by assuming the backup works.
- A recorded walkthrough of the system and the deployment, so the knowledge does not depend on one person answering a call.
- Where the software writes into the books it inherits the logging control an external audit already tests: an unalterable, timestamped record of each entry and each later change, which is control A.8.15 of ISO/IEC 27001, retained for as long as the record-keeping rules in your own jurisdiction require.
- Where the application holds personal data, the General Data Protection Regulation applies wherever those people are in the EU or the UK, and an equivalent regime applies elsewhere. Purpose, consent records, retention and a deletion path are designed into the schema rather than migrated in later.
06 The people
Who do you actually work with?
Four founders, named. A custom build has one technical owner from the specification to the runbook, and rotating that person is the fastest way to lose a project.
The person who writes the specification is the person who builds against it, and the person who hands you the runbook at the end.
-
Dhanush Prabha
Co-Founder, CTO and CMO
Writes the specification, designs the architecture, ships in fortnightly slices, and sets up the environments.
-
Sriram Ravichandran
Founder and CEO
Turns what the business needs into scope you can sign off, and owns the schedule against it.
-
-
07 Cross-border
How do we work with clients in another country?
None of this needs you to be in any particular country. The work is remote either way, so these are the answers a buyer asks for before signing, and they are the same on every engagement we run.
Working hours
Our day runs on UTC+5:30. The overlap window with your team is written into the scope rather than assumed, and everything outside it runs asynchronously.
How we communicate
One written update a day on the channel you already use, a standing weekly call inside the overlap window, and a named person to escalate to. Nothing important is agreed only on a call.
Who you contract with
Synerdyn Private Limited, the company behind IncorpX, named in the agreement with its registration number. The governing law and the forum are agreed before you sign, not after a dispute.
Currency and payment
Invoiced in your currency or in ours, your choice, and settled by bank transfer. Milestones are tied to deliverables you can see, never to elapsed time.
What you own
Copyright in everything built for you is assigned on final payment: source code, design files, prompts, configuration and documentation. Third-party licences are listed by name so nothing is a surprise later.
Where data sits
You choose the region your data is stored and processed in, and the answer is written down before the build starts, with who at IncorpX can reach it and for how long.
Offset from our working day standard time
- London-5:30
- Dubai-1:30
- Singapore+2:30
- Sydney+4:30
- New York-10:30
- San Francisco-13:30
IncorpX is a brand of Synerdyn Private Limited. The contracting entity, the governing law and the invoicing currency are all named in the proposal before you sign anything.
08 Reference
Terms used on this page
- Discovery
- A fixed-price phase producing user stories, the data model, the integration list, non-functional requirements and an estimate range. Owned by you.
- Releasable slice
- The smallest version with which a real user can do real work, delivered before the rest of the scope is built.
- Non-functional requirement
- A requirement about how the software must behave rather than what it does: concurrent users, response time, uptime, recovery time.
- Total cost of ownership
- Written TCO: the three-year cost including hosting, maintenance, patching and change.
- Runbook
- The written procedure for deploying, monitoring, backing up and recovering the system. What makes a handover real.
- Technical debt
- Work deferred to ship sooner. Acceptable when named and recorded, expensive when hidden.
- CI pipeline
- Written CI: the automated build and test run on every change, which is what stops a fix breaking something else silently.
- GDPR
- The EU and UK data protection regime. Article 83 sets administrative fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher, which is why consent, retention and access control are build decisions here rather than paperwork.
09 Questions
Custom software FAQs
Next step
Tell us the problem, not the feature list.
You get an honest view on whether a package would do it, and if not, a fixed-price discovery that produces the specification and the estimate. The specification is yours either way.
Read by Dhanush Prabha, our CTO, not a form queue. Reply usually within one working day, in your time zone.
