Work at INIT,for people who takea task end to end.
The work here sits across two products at once: bespoke sites for clients, and a SaaS platform where a ready-made site is taken on subscription and edited by its owner. Three tracks are open — frontend, design and content. Below is what the work actually is, how hiring runs, how the job is set up day to day, and how to apply.
3
open tracks: frontend, design, content
2
products in one team: the studio and the platform
Almaty
or remote — shared hours matter, an address does not
Who we are looking for right now
Every role has a test attached. It is optional, but an application that arrives with one is read first: we already see how you think, so the conversation does not start with “tell us about yourself”.
08
Frontend developer (React / Next.js)
- Level
- Middle
- Track
- Frontend of both products
- Work format
- Almaty or remote
- Employment
- Full time
The sections you write land in the builder, and from there a salon or garage owner edits them — not a developer. So a component has to survive somebody else's three-line heading, a missing image, and the same text in Kazakh. The work is split between the studio's own site and the client sites running on the platform; it is one stack either way.
DetailsCollapse
What you would do
- Build builder sections: each one is a component with a content schema that a business owner then edits without you
- Take a design to code so that it holds up against someone else's logo, a long heading and an empty field
- Keep all three locales in every string — ru, kz and en come from data, and text hardcoded into JSX is a bug, not a detail
- Work out why a section broke for one specific client, using their content rather than the demo data
- Check the result at 360 pixels and on the live site, not only in Storybook
What we need
- You write React and TypeScript so that the types describe the data instead of silencing the compiler
- You know what a server component does in the App Router and why useState will not work inside one
- You can tell state that belongs in the URL from state that belongs in the component
- You read other people's code and fix it in place instead of rewriting the module
- You do your own markup: turning a Figma file into HTML does not require a second person
Nice to have
- You have worked on a multilingual interface and know exactly where layouts break in translation
- You have touched Laravel or any other backend — the line between the admin panel and the frontend stops being a mystery
- You have written components that a user, not a developer, configures
Tools
- React
- Next.js
- TypeScript
- Tailwind CSS
- App Router
- Storybook
HTML / CSS developer
- Level
- Junior / Middle
- Track
- Studio, client sites
- Work format
- Remote
- Employment
- Full time or per project
Most of the work is the sites the studio builds to order: the design arrives in Figma and you produce markup nobody has to rewrite afterwards. The rest is sections for the platform builder, where the layout has to hold content you will never see. Writing JavaScript is optional here; reading it is not.
DetailsCollapse
What you would do
- Build client site pages from the design, including the states the design does not show: an empty field, an overlong name, one card instead of six
- Build builder sections so that a business owner can swap the text and the images without breaking anything
- Check every screen at 360 pixels before you check it on a desktop
- Move typography and spacing onto theme tokens instead of magic numbers in the stylesheet
- Repair layouts on live sites after a client's own edit has knocked something out of place
What we need
- You lay a design out in flexbox and grid without hesitating, and can say why you picked one over the other
- You write semantic markup: headings in order, a button that is a button, a link that is a link
- You know what min-width: 0 does to a flex item and why a long word sometimes tears a column open
- You can work in Figma as a reader: pull measurements, find a component, leave someone else's file intact
- You treat responsive as the behaviour between breakpoints, not as three separate designs
Nice to have
- You have built HTML email or something else with hard constraints — it teaches good habits
- You know Tailwind and do not take utility classes as a personal insult
- You can write restrained animation in plain CSS without reaching for a library
Tools
- HTML
- CSS
- Flexbox
- CSS Grid
- Tailwind CSS
- Figma
Backend developer (PHP / Laravel)
- Level
- Middle / Senior
- Track
- Platform and CRM
- Work format
- Almaty or remote
- Employment
- Full time
There are two backends in one stack here: the studio's CRM, which holds leads, briefs and deals, and the multi-tenant platform, where every client gets their own database and their own domain. Most of the time goes not into CRUD but into the question “what happens for the second tenant” — nearly every bug shows up as “it works for one of them and not the other”. The admin panels are built in Filament, so a form is PHP too.
DetailsCollapse
What you would do
- Write platform modules — the section catalogue, plans, subscriptions — so that a new type plugs in by registering itself rather than by editing the core
- Hold tenant isolation: a query that quietly reaches another tenant's data is an incident, not a small bug
- Build admin screens in Filament: resources, forms, tables, actions
- Carry a lead from the site through to a card in the CRM: validation, source, notification, the same person coming back a second time
- Write migrations that can be rolled back, and cover with tests whatever you cannot verify by looking
What we need
- You are comfortable in Eloquent — relationships, N+1, scopes, casts — and you can picture the SQL that comes out
- You write migrations with a down side and are not afraid to run them against data that already exists
- You have a couple of years of Laravel in production behind you — not because we count years, but because there is nowhere to rehearse a migration on live data
- You can add an extension point to someone else's module instead of one more condition in the core
- You test what you write; Pest or PHPUnit, either is fine
Nice to have
- You have worked with multi-tenancy, or at least understand how it differs from a company_id column
- You have built admin panels in Filament and know where it ends and your own code begins
- You have used Octane or another long-lived worker — state leaking between requests stops being a surprise
Tools
- PHP 8
- Laravel
- Filament
- PostgreSQL
- Pest
- Docker
UI/UX designer
- Level
- Middle
- Track
- Design for the studio and the platform
- Work format
- Almaty, office in the centre
- Employment
- Full time
A design here rarely reaches production as a picture: colour, type and spacing move into theme tokens, and the client then changes them from their own admin panel. So the job is not one beautiful screen but a theme that survives somebody else's logo, a photo taken on a phone, and a heading that wraps onto two lines. The niches differ — dentistry, a beauty salon, a garage, a shop — and they have to look different while being assembled from the same sections.
DetailsCollapse
What you would do
- Build themes for the ready-made sites in the catalogue: palette, typography, spacing — as a set of values, not as a single mockup
- Draw new builder sections together with their states: empty, one item, text that is far too long
- Test a theme against a client's real content rather than against carefully chosen stock
- Hand designs to development with nothing left to guess: components, auto layout, named layers
- Rebuild existing screens once it becomes visible that people get lost in them
What we need
- You build interfaces out of components and auto layout instead of nudging rectangles around
- You can defend a decision in words: why this size, this contrast, this order of blocks
- You keep contrast and type size inside the range where the site is readable on a phone outdoors
- You know the difference between a theme variable and a colour baked into a layer, and you work the first way
- You show the mobile view straight away, not as an appendix to the desktop one
Nice to have
- You have designed for a builder or for templates — somewhere the content is changed by someone other than the designer
- You read enough markup to know what your auto layout will turn into
- You have worked on multilingual interfaces: a Kazakh line is longer than a Russian one, and it already shows in the design
Tools
- Figma
- Auto Layout
- Figma Variables
- Design tokens
- Storybook
Content editor
- Level
- Middle
- Track
- Content for the studio and the platform
- Work format
- Remote
- Employment
- Per project or full time
Copy for client sites and for the platform itself, and almost always in three languages at once. The Kazakh version is not a formality here: a site whose kz page exists but is written in Russian is worse than a site with no kz at all. Beyond the paragraphs, the structure is yours too — which sections a dental clinic needs, which ones a garage needs, and the order a reader will meet them in.
DetailsCollapse
What you would do
- Write copy for the ready-made sites in the catalogue, niche by niche — clinic, salon, garage, shop — each with its own vocabulary
- Turn a client brief into a page structure rather than one long “about the company” text
- Run all three language versions so that kz and en are written rather than pushed through a translator
- Cut other people's copy: drop the “dynamically growing company” and keep what the client actually does
- Write interface strings — button labels, error messages, empty states — where length matters more than elegance
What we need
- You write clean, short Russian, free of officialese and of “unlock your potential”
- You can show copy that stood on a live site and explain what each paragraph was doing there
- You have Kazakh at working written level — or you say up front that you are taking ru and en only
- You separate the structure of a page from its length, and can see which section does not belong
- You go and get the facts: you ask the client for numbers and specifics instead of inventing them
Nice to have
- You have written SEO copy — but the kind a person reads, not only a crawler
- You have written for niches from the catalogue: medicine, beauty, automotive, retail
- You can edit someone else's translation, not only write from scratch
Tools
- Glvrd
- Figma
- Markdown
- Google Docs
- Yandex Wordstat
SEO specialist
- Level
- Middle
- Track
- Platform, the technical side
- Work format
- Almaty or remote
- Employment
- Full time
The unusual part is the scale: what you optimise is not one site but the sections all 26 ready-made sites in the catalogue are assembled from. A markup mistake in a single section reaches every site that uses it at once — and so does the fix. On top of that there are three language versions, each on its own address, so hreflang is not a theoretical topic here.
DetailsCollapse
What you would do
- Audit builder sections for markup — heading levels, alt text, structured data — before a section reaches the catalogue
- Own the technical layer: sitemap, canonical URLs, hreflang across ru / kz / en, redirects
- Work out why one specific client site is not being indexed and carry it through to a code fix, not to a report
- Build keyword sets for new catalogue niches and hand them to the editor as a page structure
- Treat page speed as an SEO task and bring developers a specific place, not an overall score
What we need
- You read Search Console as a working tool: you see the difference between “not indexed” and “excluded on purpose”
- You understand how rendering works in Next.js and why some content may never reach the index
- You can set up hreflang for three languages and explain what breaks when it is wrong
- You work with a crawler — Screaming Frog or an equivalent — and find the problem before the client does
- You brief a developer as “this tag is here, it should be that” rather than “we need better SEO”
Nice to have
- You have experience with Kazakh-language search results, not only Russian ones
- You have done local SEO: maps, branches, reviews
- You edit the markup yourself when the fix is a couple of lines
Tools
- Google Search Console
- Yandex Webmaster
- Screaming Frog
- Ahrefs
- Lighthouse
- Next.js
Project manager
- Level
- Middle
- Track
- Studio, client projects
- Work format
- Almaty, with client visits
- Employment
- Full time
One person stands between the client and the team, and that person is you: brief, deadlines, revisions, sign-off. Projects are short and run in parallel, so the real work is not a Gantt chart but wording — turning “like our competitor's, only more solid” into a task a designer and a developer will read the same way. Deals and leads live in our CRM, and keeping it honest is also your job.
DetailsCollapse
What you would do
- Take a brief that contains answers rather than a restatement of the questions: what the business is, who its customers are, what counts as done
- Convert a client's revision into a task with a checkable outcome before a designer ever sees it
- Hold the deadlines of several projects at once and warn about a slip in advance, not on delivery day
- Keep deals in the CRM so that a card's status matches reality — otherwise the board is useless
- Run sign-off yourself: open the finished site on a phone and walk through it, instead of sending the client a link
What we need
- You can write a task that two different people will carry out the same way
- You can tell a client “no” and “that will cost more” calmly, with an argument rather than an apology
- You hold several projects at once without mixing up whose revision is whose
- You know enough about the web to tell twenty minutes from two weeks without asking a developer
- You write well enough that nobody has to rewrite your email to the client
Nice to have
- You have worked in a studio or agency and have seen a project where the client changed their mind mid-build
- You speak Kazakh — some clients prefer it
- You have configured a CRM, not only used one
Tools
- Filament CRM
- Lead kanban
- Figma
- Google Sheets
- Telegram
Customer support specialist
- Level
- Junior
- Track
- Platform support
- Work format
- Almaty or remote
- Employment
- Full time
The person writing to you owns a salon or a shop, edits their own site in the builder, and has broken something — usually they have not broken it, they just cannot find it. The conversation happens in ordinary language, and “the button disappeared” has to become an understandable cause rather than being forwarded to a developer as is. A separate part of the job is noticing the question that has arrived for the third time: that is no longer support, it is an interface task.
DetailsCollapse
What you would do
- Work through platform tickets: reproduce the problem in the builder yourself before pulling in a developer
- Walk a new client through the first steps: pick a ready-made site, change the text and the phone number, publish
- Open a task for what really is a bug — with reproduction steps and the page address, not with one screenshot
- Collect the questions that keep coming back into a list and take it to the people who build the interface
- Answer in the language the client wrote in — some of them write in Kazakh
What we need
- You write calmly and clearly even when the person on the other side is already annoyed
- You ask three specific questions instead of one “please describe it in more detail”
- You can find your way around a browser: console, screenshot, private window, checking on a phone
- You take a ticket through to closed and come back to the client yourself, without waiting to be chased
- You speak and write both Kazakh and Russian
Nice to have
- You have used a website builder or a CMS from any side, even as a customer
- You know enough HTML to look at what is wrong with an image or a link
- You have support experience where the answer was not read off a script
Tools
- Filament CRM
- Lead kanban
- The INIT builder
- Browser DevTools
- Telegram
Three tracks, and what actually sits behind each one
The names are the ones we have always used. What changed is that behind each of them is a product, not a single task — one used by salon owners, garages and shops, people who have never opened a code editor in their lives.
You are not arriving at a blank page
26
ready themed sites
The platform catalogue: dentistry, barbershop, furniture and twenty-three more niches
35
section kinds in the builder
Each one a separate component with its own content schema
19
tools in the admin assistant
It edits content in the admin panel and always waits for a human to approve
3
languages in every interface
Russian, Kazakh, English — three full versions, not a toggle
Five steps, and after each one you know where you stand
The order is firm: we do not invite anyone to talk before looking at their work, and we do not set a task before explaining the terms. Silence after an application is bad practice, not neutral.
Apply through the form at the bottom
Your track, two or three links to work, and a couple of lines on what in them was yours. A CV is optional; a portfolio with no commentary is close to useless — the picture never shows which part you did.
An enquiry on our working board
We go through the work
Not the number of projects but one or two things carried to the end: how the code is put together, what the layout does at 360 pixels, how the Kazakh text looks.
Everyone gets a reply — including a no
A 40–60 minute conversation
About context, not an algorithms quiz: what you did, where it got hard, what you would decide differently now. In the same hour we walk you through how the job is set up from the inside, so you see it before you start rather than after.
A clear picture of the actual work
A small task from the real backlog
Not an invented exercise about a company that does not exist, but a piece of genuine work with a time limit. If it takes longer, we described it badly — that is our problem, not yours.
A shared language before the start, not after
Terms and start
We agree on hours, overlap and your first area of responsibility. The first task is small and real, so that within a week you go through the whole cycle: branch, review, release, a client's live site.
Your first task in progress
What you get here — and what you will never meet here
The first column works from the first minutes. The second is what we dropped on purpose: every line in it gives you back a week that other places lose to approvals.
There is
Checkable things, not values from a slide
- Direct access to whoever decides: approval in one step
- A whole task, from brief to a live site — not a slice of someone else's breakdown
- The right to argue with a brief when you can see where it leads
- Code review and layout critique instead of a silent merge
- Influence over the builder itself: sections and themes go into all 26 themed sites
- One shared call a week; everything else in writing
What you will never meet
Dropped on purpose, and staying dropped
- Endless approvals and micromanagement: a decision takes one step
- A brief handed down from above: you shape it with the person who decides
- Work that sits in a drawer: what you make goes onto clients' live sites
- Status meetings for their own sake: one shared call a week, the rest in writing
- Invented test exercises about companies that do not exist: the task comes from the real backlog
- Silence after an application: everyone gets a reply, including a no
What a week is made of
What the screen becomes is your call: nobody here rewrites your work behind your back or sends you round three approval loops over a typeface.
Nobody stands over your shoulder or counts your hours — what counts is the result, live on a client's site. The rules that do not exist yet, you will write: that is the norm here rather than the exception, and everyone who arrives after you then works to them. It is the fastest route from doing the work to setting the standard.
Terms, and what you meet in the first month
There is not a line below you could not verify in your second week. If any of it stops being true, we change the page rather than the explanation.
Terms
What you will meet
What counts as a strength here
The list is short and specific — which is the point: you can tell before the first conversation whether this place suits you.
Asking the question before starting the work
Half our mistakes are the wrong thing, built carefully. An awkward question on day one is cheaper than a rebuild in week three, and we would rather have the first.
Taking revisions calmly
A client is allowed to change their mind. A revision is part of the cycle, not a verdict on you; what counts is redoing it without drama and without quiet sabotage.
Caring what a stranger will see
The site opens on a phone, on a poor connection, and the text on it is in Kazakh. If that is what you check — not just the layout on a large monitor — we will get along.
Carrying it through to live
The work does not end at the merge. Done means it opens on a real site and works for the client, not that it passed review.
What people ask before applying
The six questions that come up most often, answered directly. If yours is not here, put it straight into the form.
Tell us what you have worked on, and add the links
The form below creates a real enquiry: it lands on the same board where we handle client requests, and a person reads it. In the message field name your track — frontend, design or content — and add two or three links to your work.
- The enquiry reaches a person, not an autoresponder
- Work is reviewed within three working days; a no comes too
- Any link format works: a repository, Figma, Behance or a PDF
Read next
Neighbouring sections that answer the question this one raises.
