Service 04 · Custom Applications
Requirements no off-the-shelf app covers. Built from your spec — with a release in week 2.
A customer portal to check order status and download certificates. An internal tool replacing 7 spreadsheets for stock, scheduling, and approvals. An old ERP connected to a new dashboard without deleting history. A 5-step process automated into 1 click with an audit trail. You write the requirement in everyday language. I analyse it, define the scope, and give you a written proposal (fixed cost, timeline, KPI) — before a single line of code is written. First release in week 2. Weekly demos. You test, we refine.
Request a Free AuditThe Problem
4 situations where custom software makes sense — not a luxury.
Custom software is not automatically "better". Custom usually costs more, takes longer, and carries more risk. But in the 4 situations below, custom is actually cheaper and faster than buying SaaS and then patching its gaps. I will not sell you custom work if an existing package is enough. The Initial Audit will be honest: "this is overkill, use this instead."
Requirements spread across several SaaS tools that do not connect
Customer portal (SaaS A) + internal portal (SaaS B) + combined reporting (manual export and merge in Excel). 3 vendors, 3 bills, data out of sync. One custom app = one source of data, one cost, one interface.
A unique process no industry standard covers
Half the workflow follows a standard (a SaaS can handle that). The other half: 15 years of internal habit, rules specific to one large customer, logistics specific to a region. SaaS "configuration" is not enough — it needs custom logic. Custom from the start is faster than SaaS plus 50 workarounds.
An old system that cannot be replaced but has to be extended
A 15-year-old ERP, running on an on-premise server, with no modern API. What is needed: a real-time dashboard for management, a supplier portal, and a mobile app for sales. A custom middleware layer: read the legacy database → expose an API → build a modern frontend. The old system keeps running, and the business gets modern tools.
Features piling up in SaaS → costs rise, performance drops
It starts with "we need a CRM". Then "add inventory". Then "add project management". Then "add an approval flow". In the end: $500 per user per month, a 10-second load, and users who hate it. Custom: pay for development once, $200 a month for hosting, only the features you use, pages that load in under 2 seconds.
How It Works
4 steps. Step 1 is yours. Steps 2–4 are mine.
- 01You
You write down the requirement — in everyday language
Like explaining it to a colleague: "We need a customer portal to see PO status, download COA, and chat with our team. Right now: 5 back-and-forth emails per PO." No user stories, wireframes, or technical terms needed. I translate it into a specification.
- 02Me
I analyse it and send a written scope
The breakdown: must-have features, nice-to-have features, and parts that are better bought than built. Estimates: fixed cost per phase, a week-by-week timeline, success KPIs, risks, and mitigations. A 2–3 page document. You review, we align, then you sign off.
- 03Me
A written proposal — fixed cost, not hours
Final scope, cost per release (not per hour), a two-week release schedule, and post-release support SLAs. You pay per completed milestone. If the scope changes: a written change request and the additional cost are approved first, then work starts. No surprise invoices.
- 04Me
Build in stages — release in week 2, then every 2 weeks
Release 1 (week 2): the core flow works and users can test it. Release 2: further features. Release 3: integrations. Release 4: polish and migration. Every release: a 30-minute demo over Zoom, you test in staging, feedback → fix → production. You see progress, not status reports.
What I Often Build
Patterns that repeat across B2B clients. Faster because the groundwork exists.
If your requirement looks like the list below, development is faster because the foundations and components already exist. If it is genuinely unique, we build from scratch.
B2B Customer Portal
See PO status in real time, download COA/COC/certificates, submit a claim or return, and chat with your PIC — without email. SSO login (Google/Microsoft/SAML). Audit trail: who downloaded what, and when.
Internal Tools (Replacing Spreadsheets)
Multi-location warehouse stock, production and machine scheduling, multi-level approvals (manager → director → finance), HSE/quality records. Input validation, audit trail, role-based access. Mobile-friendly for field staff.
Integrations & Middleware
Connect a legacy ERP (database/CSV/SOAP) → a modern API → a new frontend / a SaaS partner / a mobile app. Real-time or scheduled sync. Error handling and retries. A failed-message queue for monitoring.
Dashboards & Business Intelligence
Real-time KPIs: pending orders, production rate, on-time delivery, product failure rate, and inventory turnover. Drill down to the detail. Updated automatically. Scheduled exports to email/Drive. Role-based access.
Automating Recurring Processes
Example: a PO arrives by email → extract the data → check stock → create the SO in the ERP → send a confirmation to the customer → assign it to logistics. 5 manual steps become 1 trigger. Safe to run repeatedly, with a complete audit trail.
Specialised Tools (the Ones With No Name)
A problem only your company has. Example: complex pricing based on real-time commodity prices + logistics cost per island + margin per customer tier. There is no SaaS for this. Custom is the only way.
The Limits
What I do NOT take on — and why that protects you.
Custom projects fail in the same pattern: the scope is never written down → everything gets a "yes, we can do that" → the timeline blows up → the cost blows up → the relationship breaks. I put this list on the table up front, before the contract. These are not my limits. They protect your investment.
Applications built to be sold as a product (SaaS/white-label)
I build for your team to use. A product for the market needs billing, onboarding, tiered support, compliance, multi-tenancy, security audits, and public documentation. That scope is 5–10x bigger. If that is the goal, say so at the start — I will point you to a specialist partner.
Taking over maintenance of inherited code (legacy takeover)
I can maintain code I wrote myself. Someone else’s code: no docs, no tests, an unfamiliar architecture, outdated dependencies. It is often more expensive to maintain than to rewrite. If you need a takeover: I audit first (priced separately), then quote for maintaining it OR rewriting it.
Guaranteeing specific business KPIs (such as "a 20% sales increase")
What I guarantee: the code runs, the deploy is smooth, 99.9% uptime, critical bugs fixed in <24 hours. Business KPIs (sales, conversion, efficiency) depend on your process, your team, your market, and your product. I build the tools that make them possible — but the business outcome is a shared responsibility. We set the technical KPIs (uptime, latency, error rate) that I control.
Hidden scope creep ("just a small addition")
Every new request is a written change request: what, why, what it costs, how many extra days. You approve → then I build. This is not bureaucracy — it is what stops a 3-month project from becoming 12 months with no extra budget. I have seen too many projects die from this.
The Outcome
What you get when the project is finished.
An application that follows your business — not the other way around
Your workflow becomes the application logic. Not "use this feature this way", but "my process works like this, and the application follows".
Scope and cost in writing before the first line of code
No "it turns out we need this too". Everything is written down, approved, and in the budget. A change means a written change request + approval.
Small releases you can test and use from week 2
Not "6 months later you finally see something". Week 2: the core flow works. Week 4: the next features. You use it, users test it, feedback → fix. Risk is reduced from the start.
The code, the documentation, and full access — yours
A private Git repository (GitHub/GitLab) → you own it. Documentation: architecture decision records, an API specification (OpenAPI), an operations guide, and an incident guide. Credentials: server, database, DNS, monitoring — all in your password manager. I do not hold the "keys" after handover.
FAQ
The questions I get most — answered honestly.
What does it cost — a realistic range?
A simple customer portal: Rp 150–300 million. A complex internal tool: Rp 300–800 million. Legacy integration + dashboard: Rp 400 million–1.5 billion. An enterprise platform: Rp 1 billion+. The Initial Audit (free) → a proposal with fixed numbers per phase. Not a wide range. The final number follows the final scope.
How long until it is finished?
The first release (core flow running): 2 weeks. Full scope is usually 2–4 months (8–16 two-week releases). What decides it: integration complexity, how ready the legacy data is, and how quickly you give feedback. The Initial Audit gives a timeline with buffers — not a best-case scenario.
Do I need to be technical to work with you?
No. A requirement in everyday language is more useful than a technical spec. Technical specs written by non-technical people often: (1) miss important cases, (2) over-spec the simple things, (3) under-spec the complex ones. Tell me the problem the way you would tell a colleague. I translate it into architecture.
What if the requirement changes during development?
That is normal. A change means a Change Request: what, why, the cost impact, the schedule impact. You approve → then it gets built. This protects you from the scope creep that makes projects drag on forever. I log every change request in Notion/GitHub — transparently.
Do I really own the code? Can it be handed over to my internal team?
Yes. The GitHub/GitLab repository: you own it from day one. I am a collaborator. Handover: (1) architecture decision records, (2) the OpenAPI specification, (3) deploy/operations/incident guides, (4) credentials in your password manager, (5) 2 knowledge transfer sessions of 2 hours each with your team. No lock-in.
When is custom better than buying SaaS?
When: (1) requirements are scattered across 3+ SaaS tools that do not connect, (2) the process is unique and not available on the market, (3) an old system has to be extended rather than replaced, (4) the annual SaaS cost is bigger than custom development + hosting. If only 1–2 features are truly unique → SaaS + integration is faster and cheaper. The Initial Audit will recommend that honestly.
Send your requirement in 1 paragraph. I send back the scope and an estimate — free.
Example: "We need a customer portal to check PO status and download COA. Right now that is 5 emails per PO. ERP: SAP B1. Users: 50 customers + 10 sales." Send it by WhatsApp/email. Within 24 hours: a draft scope + cost estimate + timeline. A good fit? We move on to the Initial Audit.