Memora
A simple guest flow. The system behind it.
Web application · Media handling · Production infrastructure
Private QR-based contributions with event access, mobile uploads, storage and export behind the guest experience.
Read the case studyWeb applications
Web applications
built around the work.
We build customer portals, dashboards and internal business systems with working data, clear permissions and connected workflows.
Bring approved designs, workflow requirements and the services to connect. View pricing
Selected project
Selected application engineering
Real tasks.
Working systems.
Guest contributions and business operations from the existing work. Each case study records the actual responsibilities; the starting scope below covers a focused workflow.
Pastelocity
From an order to the next action.
Product development · Backend services · Integrations
A business system connecting customers, products, orders, payments, receipts and daily administration.
Read the case studyOur process
How an application
build runs.
See the weeks, the review points and what each stage produces. Orange and navy show Axelyn’s work; grey shows your part.
Illustrative planning schedules for one defined workflow and up to five key screens. Design readiness, user roles, data, feedback and service access determine the delivery dates agreed in your proposal.
Development Example 6-week plan
Approved designs, working application services and an agreed release
Scroll across the schedule, then select a stage to see its deliverables.
| Workstream | Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |
|---|---|---|---|---|---|---|
| Your partDesigns, workflow context and reviews | ||||||
| Technical planningData, permissions and service boundaries | ||||||
| Application developmentScreens, backend services and connections | ||||||
| Checks & releaseVerification, deployment and handover | ||||||
Your part · Weeks 1–2
Designs & access
Provide approved designs, the workflow and role requirements, anonymised sample data and authorised access to agreed services.
Review outcomes
- Design and data readiness checklist
- Acceptance criteria and access responsibilities
Your part · Weeks 3–4
Preview review
Review the working journey with representative inputs and consolidated feedback.
Review outcomes
- Reviewed workflow and screen behaviour
- Recorded corrections within scope
Your part · Week 6
Acceptance
Review the working application against the agreed tasks, roles and acceptance criteria.
Review outcomes
- Acceptance review
- Release and ownership decision
Technical planning · Weeks 1–2
Architecture & data
Review the designs and define the scoped data model, application services, access rules, API connection and deployment approach.
What you receive
- System architecture and data model
- Permission and API contracts
- Release and operational responsibilities
Application development · Weeks 2–4
Screens & interactions
Implement the approved responsive screens and the loading, empty, validation and error states around the primary journey.
What you receive
- Working application preview
- Reusable interface components
Application development · Weeks 2–5
Backend & permissions
Implement the agreed data storage, application logic, authentication and server-side permission checks where required.
What you receive
- Scoped backend services and stored data
- Validated inputs and access rules
Application development · Week 5
API connection
Connect the agreed external service and make failure handling and retry behaviour explicit for the workflow.
What you receive
- One agreed API connection
- Connection and failure-handling notes
Checks & release · Weeks 5–6
Checks & fixes
Check the primary journey, data validation, role boundaries and failure paths against the agreed acceptance criteria.
What you receive
- Release checklist
- Resolved issues within scope
Checks & release · Week 6
Release & handover
Release into the agreed environment and explain how the application is updated, observed and operated.
What you receive
- Released application workflow
- Source and configuration guidance
- Operational ownership and support arrangements
What the build covers
The screens people use.
The services behind them.
Internal workflows, backend services and APIs sit within the application scope. Agree on screens, data and permissions before implementation. System architecture, backend services and release planning are part of the build.
- Responsive application screens
- The agreed customer or staff-facing screens, with reusable interface components and layouts for relevant device sizes.
- Backend services & APIs
- The application logic, APIs, data model and storage needed for the defined workflow, with clear boundaries around the first release.
- Accounts & permissions
- Authentication and role-specific access where required, with permission checks enforced in the application services.
- Connected workflows
- The agreed API connection, data exchange and operational handoffs, including what happens when a connected service fails.
- Validation & useful feedback
- Input checks and loading, empty, confirmation and error states that help people complete the task and recover from problems.
- Deployment & ownership
- An agreed release environment, source and configuration guidance, plus a clear owner for hosting, updates and operational support.
Pricing
A focused application.
A defined development scope.
Indicative starting prices for one primary workflow and up to five key screens. Development uses supplied, approved designs and defined workflow requirements.
Approximate conversions, rounded to whole units. Frankfurter exchange rates dated . Final fees and billing currency are confirmed in your quotation.
From approved designs
Application development
Turn approved screens and workflow requirements into a working application with the agreed backend and service connection.
FromRM6,000/ project
Base price: RM6,000
Example planning schedule: 6 weeks for a bounded release
Discuss application developmentWhat’s included
- One primary workflow, with up to five key screens
- Responsive frontend, scoped backend services, APIs and data model
- Basic authentication and role checks where required
- One agreed API connection, validation and failure handling
- Release checks, deployment and source handover
Approved designs and workflow requirements are supplied. Visual redesign, complex permissions, multiple workflows, substantial migration and complex integrations are outside this starting scope.
Starting prices apply to eligible, focused engagements. A proposal confirms user roles, screen states, data, service connections, review rounds and acceptance criteria. Additional workflows, complex permissions, extensive migration and complex integrations need separate scoping. Hosting, subscriptions, third-party usage and ongoing maintenance are separate costs. Final fees, delivery dates and billing currency are agreed before work begins.
Before the application goes live
Check the whole flow.
Make ownership clear.
Release checks follow the task through the interface, application services and agreed connections.
- Responsive task flows
- Check the primary journey across the agreed device sizes, including navigation, forms and information-dense screens.
- Keyboard & accessibility
- Visible focus, labelled controls, readable contrast and a logical keyboard path through the task.
- Validation & data handling
- Check inputs, stored records and useful feedback for incomplete or invalid requests.
- Access & role boundaries
- Verify the agreed roles and server-side access checks, including attempts to reach data or actions outside a role.
- Failures & recovery
- Review service failures, retry behaviour and error states within scope, with enough information to investigate problems.
- Release & operational handover
- Verify the agreed deployment, configuration, logs and recovery guidance, with hosting and support ownership recorded.
Before we start
Questions about
your application build.
Work directly with Amin, the engineer behind Axelyn, to define a useful first release and the responsibilities around it.
Can you build from designs we already have?
Yes. We review the approved designs, workflow, user roles, screen states and data requirements before confirming the development scope. Missing decisions and technical constraints are identified before implementation. Please supply approved interface designs; this service covers their implementation.
What should we prepare for development?
Bring approved screen designs, workflow requirements, user roles, representative data and details of the services to connect. We define the application architecture, backend and acceptance checks before implementation. Standalone interface design, prototypes and design-file handover are not offered.
How much does it cost, and how long does it take?
Application development starts from RM6,000 per project using approved designs and workflow requirements. The indicative starting scope covers one primary workflow and up to five key screens. The planning example shows six weeks for development. Final fees, scope and delivery dates are agreed in the proposal. MYR is the base price; other currencies are approximate conversions, with billing currency agreed before work begins.
Can you build internal tools, backend services and APIs?
Yes. Internal business systems, backend services and APIs are scoped within the application engagement. The development starting scope includes the agreed backend and data model, basic authentication and role checks where required, and one agreed API connection. More complex access models, multiple connections, payments, migration and additional workflows need explicit scoping. Hosting and third-party usage are separate costs.
What happens after the first release?
Handover covers source access, configuration and usage guidance, operational ownership and agreed recovery steps. You can manage the application yourself or discuss optional Application Maintenance under Deployment & Reliability, starting from RM500 per month for one stable application and one environment. Scheduled checks, updates and minor fixes have an agreed monthly allocation; new features and incident response need their own scope. Hosting, subscriptions and third-party usage remain separate costs.