How Is an ikas Custom Theme Built? The Step-by-Step Process

When should you move to a custom theme?

Starting with a ready-made theme is the right call for most stores. The ikas theme editor is genuinely flexible with colours, fonts, section order and content areas. The moment I start talking about a custom theme is the moment the editor reaches its limit. I measure that with three questions:

• Can the information a customer needs to decide on the product page not be shown in the order the ready-made theme allows? If size and colour selection, instalment details, cold-chain notices or usage videos do not fit the template, the answer is yes.
• Does the team ask a developer every time a campaign changes? A lack of manageable areas becomes the most expensive problem over time.
• Are mobile speed and flow where the brand wants them? Every app and every custom code snippet added to a ready-made theme pulls the mobile score down a little more.

If two of the three are a yes, scoping a custom theme is worth it. If only the look needs to change, meaning colours, fonts and section layout are enough, solving that on a ready-made theme with ikas theme design in 1-2 weeks is the better route.

Step 1: Discovery and a written scope

In the first meeting I do not talk about design; I talk about how the store sells. What does the product structure look like: single variant, a size-colour matrix, weights? Which information does the customer decide on? How do campaigns run, which integrations exist, is there data to migrate from another platform? If the current store has analytics, we look at product-to-cart and cart-to-checkout rates together.

The output of that meeting is a written scope: which pages will be designed, which sections will be editable in the editor, what is out of scope, and the delivery date. Once the scope is clear I send a written quote within two business days; the price is set by the scope. If the scope changes later, the quote is updated in writing. Whoever you get a quote from, ask for this written scope; most later disputes come from not having it.

Step 2: Design, mobile first

Most of the traffic in the stores I build comes from phones, so I design on the mobile screen first and widen to desktop afterwards. Which information sits next to the photo and price on the product card depends on the product type: size and colour in fashion, weight and delivery details in food, usage and instalments in furniture. At this stage we moved the colour and size flow at Tarzım Süper, instalment and usage details at Massada, and cold-chain and free-shipping details at Atabarı to the decision point.

Ratios and sizes for every image area are also fixed during design so nobody has to guess when preparing images later. Design approval is one of the two things that affect the timeline most; the other is having product images and content ready.

Step 3: Choosing the technical route

One distinction needs saying plainly: most of what is sold as a "custom theme" is a ready-made theme customised with colours, sections and code snippets. I build the theme from scratch on ikas Studio or the Next.js-based ikas storefront framework, using TypeScript, starting from ikas's own documentation; the section and behaviour limits of a ready-made theme do not exist in this setup. The theme runs on ikas's own theme infrastructure and connects to the theme editor. Cart, checkout, accounts and the admin panel stay with ikas; we only write the storefront. The practical result is that the store team keeps working in the same editor after launch, only the sections are specific to the brand.

Each component is defined by a schema in code: which field is text, which is an image, which is a product list, which is a link. That schema becomes form fields in the editor. The person adding a campaign band to the homepage never sees code; they fill in a title, an image and a link. This is why the manageability scope is written down in step 1: which fields will be editable decides how the code is written.

The word "headless" sometimes comes up. In a headless setup the storefront is written as a completely separate Next.js application fed by the ikas Storefront API; more flexible, but more expensive and heavier to maintain. For the vast majority of stores a custom theme is enough. I only suggest headless when there is a concrete need a custom theme cannot solve.

Step 4: Building component by component

The build order is roughly the same on every project: first the surfaces that appear on every page, such as the header, footer, cart drawer and search; then the product card, because category, search, homepage and recommendation sections all use the same card; then the product page, category page, cart and content pages. The code is written in TypeScript, and styles are kept per component so a change in one section does not break another.

At this stage I put several things into the code from the start that ready-made themes often skip:

• Variant behaviour: colours that are out of stock become inactive once a size is chosen, price and image change with the selection, and single-variant products never show a selection step.
• Image ratio and cropping: every image area is rendered at a fixed ratio, cropped from the centre; even if the client uploads a wrong-sized image six months later, the layout holds.
• Structured data: Product, Offer and BreadcrumbList on product pages, CollectionPage and ItemList on category pages, generated by the theme itself.
• Speed: images do not load until they enter the viewport, and heavy parts such as sliders and video load on demand on mobile. Images, videos and apps added after launch change the score, so speed is not treated as finished at handover.
• App compatibility: the storefront areas for the ikas apps I have built and the third-party apps the store uses are planned from the start.

Development takes place in a development store. At set stages I share a preview; the team browses the pages on their own phones and computers and gives feedback per section by message or in a call. Before launch we go through the final preview together.

Step 5: Testing and going live

The pre-launch checklist is short but non-negotiable:

The existing store does not close on launch day. The new theme is sent to the store from the partner panel, the theme update is accepted and saved on the store side, and it is published with a single click. If something goes wrong the previous theme is still there; rolling back takes minutes. I schedule the launch for a low-traffic slot and watch the order flow with real data during the first hour.

Step 6: Handover, where the theme lives, and maintenance

At handover you get three things: the theme published in the store's own ikas account, a short document explaining the theme structure and editable areas, and editor training. Because the theme stays in the store's account it keeps running independently of me, and the team keeps managing content and campaign areas from the editor. I do not hand over the source code, because the theme code contains my own development kit, and I state this clearly in the quote; there is no closed tool or access that stays with me and creates dependency.

Bugs caused by the theme are fixed free of charge with no time limit, and when ikas ships an update that affects the theme, I adapt it. For one month after delivery, small adjustments and the places where the team gets stuck in the panel are covered by maintenance. New pages and new features are planned as separate work; the quote states with examples what counts as a bug fix and what counts as new development, so there is no argument later.

The three most common mistakes

• Starting from desktop. A product page that looks good on desktop pushes the price to the second screen on mobile. Design has to start on mobile.
• Leaving manageability to the end. If the editable fields are not written down at the start, every campaign turns into a developer request.
• Treating migration and theme separately. For a store coming from another platform, the URL structure, the 301 map and the new theme must be planned on one timeline; SEO loss happens when they are handled apart.

Timeline and next step

A typical ikas custom theme project covering the homepage, category, product and cart flow takes 4-6 weeks; combined with a migration from another platform I plan 6-8 weeks. The pace of design approval and content readiness sets the timeline more than anything else. You can see the stores launched with this process, with sector and scope, on the projects page. Scope details are on the custom theme service page, and the partnership and way of working on the ikas partner page; a message describing your store is enough, and we scope it together.