Oracle APEX lets a small team build secure web apps on top of Oracle Database quickly. That speed is the reason people choose it. It is also the risk. A team can build fifty screens before anyone checks the data model, the security or who will support the app next year.
This guide is for finance, operations and IT leaders choosing an Oracle APEX development company. It covers what a good partner should do, the skills to check, engagement models, method, a scorecard, questions to ask and red flags. If you plan to add AI features, see our Oracle APEX and OCI Generative AI setup guide.
What Oracle APEX is, in brief
APEX is Oracle's low-code platform for building web and mobile apps. It runs inside Oracle Database and is a no-cost feature of the database, so apps work directly with your tables, SQL and PL/SQL. The Oracle APEX documentation covers the platform in full.
You can run APEX in a few ways:
| Option | Who runs the platform | Suits |
|---|---|---|
| APEX service or Autonomous Database on OCI | Oracle manages backups, patching and upgrades of the APEX stack | New apps, teams without DBAs |
| Co-managed cloud database (Base Database, Exadata, Compute) | You or your partner manage the database and APEX | Existing Oracle estates moving to OCI |
| On-premises Oracle Database | You or your partner | Data that must stay in your own data centre |
| Always Free options | Oracle, with resource limits | Learning, prototypes and pilots |
Oracle describes these options on its APEX in Oracle Cloud page and in the APEX service documentation. You can try the platform at no cost with an Oracle Cloud Free Tier account.
What an APEX development company should do
A good APEX partner does more than build pages. Expect them to:
- Understand the process first. Map who does what, the approvals and the exceptions before any build starts.
- Design the data model. Tables, keys, constraints and audit columns. In APEX the data model is the application. Weak design shows up in every report.
- Build in small releases. A working pilot early, then regular increments that users can test.
- Secure the app. Authentication, role-based authorisation, data-level access and protection against common web attacks.
- Integrate cleanly. Connect to Oracle Fusion, other ERPs and external services through REST, not copied spreadsheets.
- Test and hand over. Test scripts, user acceptance, deployment scripts in source control and documentation your own team can use.
- Support the app. Fixes, small changes and APEX upgrades after go-live.
Step 1: Check the skills
APEX is low-code, not no-code. The hard parts are still written by hand. Ask for named developers and check:
- SQL and PL/SQL depth. Business rules, validations and batch jobs live here. Ask to see sample packages.
- Data design. Who designs the schema, and how do they handle history, audit and reporting?
- Security. How they set up authentication schemes, authorisation per page and per row, and session protection.
- Integration. APEX REST Data Sources can call plain HTTP feeds, Oracle REST Data Services, REST-enabled SQL on another database, OCI services and Oracle Cloud Applications (SaaS) REST services. Ask which of these they have used in production, and when they would use Oracle Integration Cloud instead.
- User experience. Responsive layouts that work on a phone in a warehouse or on a site visit.
- Oracle Database and OCI. If you are moving to the cloud, someone must understand networking, identity and the database service you choose.
Step 2: Pick an engagement model
| Model | How it works | Suits |
|---|---|---|
| Fixed scope | Agreed requirements, price and dates | One well-defined app, such as a vendor portal |
| Dedicated team | Named developers working your backlog each sprint | A programme of apps or ongoing change |
| Build and support | Partner builds, then runs support under an agreed service level | Teams without in-house APEX skills |
| Staff augmentation | APEX developers join your own team | You have a lead and need capacity |
Many companies start with a fixed-scope pilot, then move to a dedicated team once trust is built. For offshore delivery, ask which hours the team will actually work and who covers urgent issues outside them.
Step 3: Understand the method
Ask the partner to walk you through their delivery steps with sample documents.
- Discovery. Workshops, process maps, data sources and a short list of must-have features.
- Prototype. A clickable APEX prototype on real or sample data within the first weeks.
- Build in sprints. Each sprint ends with a demo to users and a deployable release.
- Integrate. REST connections to Fusion or other systems, tested with realistic volumes.
- Test. Unit tests, system tests and user acceptance testing with your process owners.
- Deploy. Scripted deployment between development, test and production, with the app export and database objects in source control.
- Support. A defined hypercare period, then steady-state support and planned APEX upgrades.
Partner evaluation scorecard
Score each company from 1 to 5. Agree the weights with your team before you see proposals.
| Area | What good looks like | Weight |
|---|---|---|
| APEX and PL/SQL depth | Named developers, sample code, production apps | 20% |
| Data design | Clear schema approach, audit and reporting plan | 15% |
| Security | Authentication, page and row-level access, review steps | 15% |
| Integration | REST Data Sources, Fusion APIs, OIC where needed | 15% |
| Method | Early prototype, sprints, demos, source control | 10% |
| Testing | Test scripts, UAT plan, regression before upgrades | 10% |
| Delivery and hours | Overlap with your day, named team, low churn | 10% |
| Support | Service levels, upgrade plan, handover documents | 5% |
Questions to ask
- Who exactly will build our app, and can we see their past APEX work?
- Who designs the data model, and can you show a sample?
- How do you control access to pages, buttons and rows of data?
- How will the app read from and write to Oracle Fusion or our other systems?
- When will we see a working prototype?
- How do you manage source control and deployments between environments?
- How do you test before an APEX or database upgrade?
- Who owns the application export, scripts and documents at the end?
Red flags
- No named developers, only roles and day rates.
- Screens shown on day one, but no questions about your data.
- All business logic hidden in page processes with no shared packages.
- Security treated as a login page and nothing more.
- Integration by nightly spreadsheet upload when an API exists.
- No source control or scripted deployment.
- No plan for support, upgrades or handover.
- Claims of Oracle endorsement you cannot see on Oracle's own pages.
APEX partner selection checklist
- Named developers with APEX and PL/SQL experience
- Sample data model and code reviewed
- Hosting option agreed (APEX service, Autonomous Database, co-managed or on-premises)
- Security design covers authentication, authorisation and data access
- Integration approach for Fusion and other systems described
- Prototype date agreed
- Sprint, demo and release plan agreed
- Source control and deployment process confirmed
- UAT plan with your process owners
- Working hours and escalation cover agreed
- Support, upgrade plan and service levels in the contract
- Ownership of code, exports and documents confirmed
How Egisedge helps
Egisedge Technologies is an Oracle Partner, founded in 2019. We build Oracle APEX + AI low-code applications and connect them to Oracle Fusion Cloud and other systems through REST and Oracle Integration Cloud. We have delivered multiple Oracle projects. Our APEX work includes systems for GST returns, HR and payroll, vendor portals with KYC, inventory, manufacturing, procurement, billing, payables and supplier qualification. Where AI helps, we add it using our APEX and OCI Generative AI playbook.
Our teams work from offices in Gurugram and Mahendergarh, India, and deliver offshore across GCC, UK/Europe, US and Australia/NZ working hours. Egisedge is a DPIIT-recognised startup, Startup Haryana (Category-1) and Udyam/MSME registered. See our Oracle APEX development services.
If you are shortlisting Oracle APEX development companies, email info@egisedge.com to talk to our team.
Frequently asked questions
Does Oracle APEX cost extra to license?
APEX is a no-cost feature of Oracle Database, so if you already license the database you can build APEX apps on it. On Oracle Cloud you pay for the database service it runs on, and Oracle offers Always Free options for trying it out. You still pay your development company for design, build and support.
Can an APEX app work with Oracle Fusion Cloud Applications?
Yes. APEX REST Data Sources include a type for Oracle Cloud Applications (SaaS) REST services, so an APEX page can read Fusion data through its REST APIs. Larger or event-driven flows often run through Oracle Integration Cloud. Your development company should agree which data stays in Fusion and which sits in the APEX schema.
Where should our APEX apps run: on-premises or in Oracle Cloud?
Both work. On the APEX service or Autonomous Database, Oracle manages backups, patching and upgrades of the APEX stack. On-premises or on co-managed cloud databases, your team or partner looks after the database and APEX upgrades. Choose based on where your data already sits and who will run the platform.
How long does a typical APEX project take?
It depends on scope, data and integrations. A focused app, such as an approval workflow or a vendor portal, can often go from workshop to pilot in weeks rather than months. Ask your development company for a phased plan with a working pilot early, not a single big release at the end.
Talk to Egisedge about APEX
Tell us where you are and we'll reply within one working day with next steps.