Custom Web Applications Built Around Your Data
Portals, internal tools and APIs built in PHP, MySQL and modern JavaScript, designed to work with Salesforce and the rest of your stack rather than around it.
Some problems do not fit neatly inside a CRM or a marketing platform. A customer portal that pulls order history from three systems. An internal tool to replace a shared spreadsheet nobody dares to edit. An ageing PHP application that still runs part of the business.
GeekMidst builds and maintains custom web applications for these situations. Our usual stack is PHP with MySQL on the server, a modern JavaScript front end, and documented APIs between the application and the systems you already run. If your organisation has standardised on a different language, framework or hosting platform, we work within it instead of adding another stack for your team to support.
Who this service is for
- Operations and product owners who need a working tool for a specific process, with proper roles and an audit trail.
- Salesforce platform owners whose org is being stretched into jobs it handles poorly, such as heavy public traffic from anonymous users or complex custom calculations.
- IT teams inheriting a legacy PHP application with no tests, little documentation and an unclear upgrade path.
We will also tell you when a custom build is the wrong answer. If your users already work in Salesforce every day, a Lightning Web Component or an Experience Cloud site is often simpler to secure and maintain than a separate application.
Where this connects to the rest of your platform
Integration with Salesforce
Applications that read and write Salesforce data through its APIs, with clear ownership of each field and a plan for failures and retries.
→API security
Authentication, least-privilege integration users and secrets kept out of source code, so a web app never becomes the weak point in your org.
→Salesforce-native interfaces
When the audience is internal Salesforce users, we compare a custom app with Lightning Web Components before anything is built.
→Portals on Experience Cloud
For logged-in customers or partners, Experience Cloud can be the better route. We weigh licensing, design freedom and data access with you.
→Testing and release
Automated tests for business rules and APIs, plus a release process your team can repeat without us.
→How we choose the technology
| Typical choice | When it changes | |
|---|---|---|
| Server side | PHP with a maintained framework, or plain PHP for small services | You already run another language in production and have people to support it |
| Database | MySQL or a compatible engine | Your organisation mandates a different relational database or a managed cloud service |
| Front end | Modern JavaScript, using a framework only where the interface needs one | Simple forms and content pages are often better as server-rendered HTML |
| APIs | REST with JSON and versioned endpoints | An existing integration platform or event bus is already your standard |
| Hosting | Your cloud account or servers, under your control | Your security team requires a specific platform, region or deployment pipeline |
How a build runs
- 01
Discovery
We map the users, the process, the data each screen needs and where that data lives. Unclear ownership of a field is resolved here, not during testing.
- 02
Architecture and estimate
A short technical design covering components, data model, integrations, authentication and hosting, with a phased estimate you can challenge line by line.
- 03
Thin first release
One complete path through the application is built end to end and put in front of real users in a test environment early.
- 04
Iterative build
Features are added in short cycles, with working software reviewed at each step.
- 05
Testing and hardening
Functional, integration and security testing, including input validation, access control checks and behaviour when a connected system is unavailable.
- 06
Launch and handover
Deployment to your environment, monitoring, documentation and a walkthrough for whoever supports the application next.
What you receive
- Source code in your repository, under your organisation's ownership.
- A technical design document and an API reference for any endpoints we build.
- Database schema and migration scripts, so the data model can be rebuilt and changed safely.
- Automated tests for the business rules that matter most, and instructions for running them.
- A deployment runbook and notes on monitoring, backups and routine upgrades.
Dependencies and risks to plan for
We will need a product owner who can make calls on scope, access to sandboxes or test instances of connected systems, and early agreement on hosting and security requirements. The most common risks are unclear data ownership between systems, requirements that grow faster than the budget, and hosting decisions left until the end. We raise these early and keep a visible list of open decisions throughout the project.
{
"error": {
"code": "ORDER_NOT_FOUND",
"message": "No order exists with reference ORD-10042.",
"request_id": "7f3c2a9e-example",
"retryable": false
}
}Questions we hear
Can you take over an existing PHP application?
Do you only work in PHP?
Should this be a custom app or something inside Salesforce?
Who owns the code?
Have an application in mind, or one that needs rescuing?
Tell us what the tool needs to do and which systems it must talk to. We will suggest a sensible first release and the decisions to make before building.
