Front-end markup is often treated as mechanical work: move the mockup into the browser. In reality this is where a decision gets made that is expensive to undo later. Will the product survive long text, a second language, a narrow phone screen and new sections? If the markup is built around a single picture, every later design change costs as much as a small project.
This is the fifth stage of our app development strategy and the first one where mockups turn into live pages. Below: what exactly is done, what you get at the end, what drives the price and what cutting corners leads to.
What happens at this stage
- Responsive markup based on the mockups from the interface design stage. Every screen is checked at phone, tablet and laptop widths.
- Work on the HTML, CSS, Bootstrap, AdminLTE and FontAwesome stack. Bootstrap provides the grid and responsiveness, AdminLTE speeds up admin screens, FontAwesome covers icons.
- PWA preparation for iOS and Android, so the product can be installed on a phone like an app.
- Repeating elements are built as components: buttons, fields, tables, cards, modal windows. A component is changed in one place and the change reaches every screen.
What you get at the end
- Marked-up pages and screens that open in the browser and behave the same way on different devices.
- A component set from which new pages are assembled without starting the markup from scratch.
- A PWA foundation: the product goes onto the phone's home screen without app stores.
- A ready base for the next stage, where pages start responding to what the user does.
How much front-end markup costs and what drives the price
In the Ingello price list the interface markup stage costs from $0 to $2,400. The stage price is fixed before work starts, and the result is accepted against a list of finished screens. The lower bound means that not every project needs a separate budget for this stage: the scope depends on what was already done in earlier stages and how many unique screens the product needs.
Within the range, the price is driven by several factors:
- the number of unique screens and their states in the mockups;
- how many screen widths and devices need to be supported;
- how many interface languages there are and how long the texts run in them;
- whether the admin panel needs a branded look or a standard theme will do;
- whether PWA preparation is needed.
We give the exact figure once the set of screens is clear. It goes into the overall stage-by-stage estimate you receive after a consultation with an architect.
Standard theme or custom markup
The admin side does not always need a unique design. In the BusTicket bus ticket sales system, the admin panel is built on the standard AdminLTE theme (Bootstrap 4). It is quick, inexpensive and familiar to operators: tables, filters and forms are where they expect them. If a business needs a branded interface, we build the admin system to a custom design as well.
The customer-facing side is what buyers see, so the markup there is usually custom. In the Rapport app for psychologists, besides the mobile version there is a web account designed for two responsive widths, 1000 and 768 pixels. Sections sit on the left, the calendar and the day's sessions on the right, and on a tablet it all rearranges without losing any features.
Why the PWA is planned at this stage
A PWA gives users an app on their phone with no app stores, no review process and no separate mobile team. But adding it after the fact costs more than planning it from the start: PWA requirements for page structure and offline behaviour affect the markup.
An example from our work: a PWA app with an admin panel (CRM) for customer and order management. It installs easily on a phone, works offline, has payments built in, and orders land in the CRM along with statistics. That combination is easier to achieve when the markup is designed for a mobile screen from day one.
This line continues in smooth interface and offline mode, part of the corporate growth block, where data caching and offline synchronisation are added.
What breaks if you cut corners
- Markup built for one mockup falls apart on long text, on a Ukrainian locale and on a narrow screen.
- It gets patched with one-off workarounds, and a year later changing a margin in one place breaks three others.
- Without components every new page is marked up from scratch, and the growth budget rises with the number of screens.
- If the PWA was not planned from the start, the mobile version has to be rebuilt rather than extended.
- Heavy markup lags on low-end phones, and people leave before they see the offer.
Speed on weak devices is also a markup question. In our domain map, areas, nodes, modules and links are drawn on a single canvas, and the interface holds 42 frames per second on a low-end phone.
What we need from you
- Approved mockups, or a decision to work with a standard theme.
- A list of the languages and devices your customers and staff will use.
- Real data samples: the longest product name, the longest customer name, the longest table. That is what we test the markup against.
Where next
Next comes interface logic: forms, validation and scenarios in JS/TS. The previous step: interface design. The map of all stages is in the app development strategy.
If you already have mockups or a prototype, book a free consultation with an architect. We will go through the screens, and after the consultation you will receive a price and timeline estimate broken down by stage.
