Options as data, not as form fields
Hard-coding print options into the layout would mean a code change for every new product. Storing options and their allowed combinations in the database let the catalogue grow without touching the application.
Back to work
PrintXpress
A digital printing service application that allows customers to browse printing products, customise orders, upload designs and track order progress.
- Android engineering and product design
- 2025
- JavaXMLAndroid StudioSQLite
Context, challenge and the part I played.
Context
Small printing businesses take orders over messaging apps, where specifications get lost and artwork arrives compressed. PrintXpress puts the whole order into one structured record.
Challenge
A printing order is a set of dependent choices — material constrains finish, finish constrains quantity pricing. Modelling that on a small screen without overwhelming the customer was the core design problem.
Goals
- Capture a complete, unambiguous order in a few screens
- Give staff a single place to see what needs producing
- Keep artwork attached to the order it belongs to
- Work reliably on modest hardware and intermittent connectivity
My role
I designed the screens and the data model, and built the application, including the role-based navigation and the order lifecycle.
From interface down to infrastructure.
Each layer, and the reasoning that shaped it.
Architecture
A layered Android application: activities and fragments for presentation, a service layer for order rules, and a repository layer over SQLite. Business rules sit outside the UI classes so they can be reasoned about on their own.
Front-end
XML layouts with a consistent spacing and type scale, constraint-based layouts for varied screen sizes, and touch targets sized for real use rather than for the emulator.
Backend
Java service classes hold order validation and pricing rules. Options are modelled as an explicit set with allowed combinations, which prevents impossible orders from being submitted.
Database
SQLite with a normalised schema for products, options, orders and users. Uploaded artwork is stored on the file system with the path referenced from the order row.
Cloud & deployment
Local-first by design for the academic scope, with the repository layer written so a remote data source could replace SQLite without touching the screens.
What the system actually does.
Customer, staff and administrator interfaces
Three roles, one application, with navigation and permissions that follow the signed-in user.
Product browsing
A catalogue of printing products with specifications, options and indicative pricing.
Artwork upload
Customers attach their own design files to an order and see them on the confirmation screen.
Order customisation
Size, material, quantity and finish are selected as structured options rather than free text.
Order tracking
Each order carries a visible status that staff update as the job moves through production.
Local data and image storage
SQLite and local file storage keep the application usable without a permanent connection.
Interface and system views.
Placeholder frames — swap for real captures once they exist.
Catalogue and product detail Order customisation and artwork upload - admin · orders
Staff order queue
The trade-offs worth writing down.
Every architecture is a set of choices. These are the ones that mattered most, and why they went the way they did.
One application, three roles
Separate applications for customer and staff would have doubled the work for a small business. Role-driven navigation kept a single codebase while making each user's view feel purpose-built.
Where it stands.
- Created a maintainable foundation for a small-business ordering workflow
- Improved separation of responsibilities between screens and business rules
- Designed for future scaling to a remote data source
Want the detail behind any of these decisions?
Start a conversation