Home / How we work
EngagementOne place for what happens after the first email, what moves the quote, and straight answers on contracts, IP, maintenance and time zones—so intro calls stay about your product, not admin.
Services we phase this way: UI/UX design · Web development · SEO & growth · Brand & design systems · Content & CMS · WordPress · 3D & rendering · AI & automation · Analytics. Pricing is on the packages page, examples in our work.
Dates shift with scope, but the order doesn’t. Share this section with colleagues who ask “when do we get a proposal?” before you book a call.
Proposals and contracts (SOW) are in Serbian for local clients and in English for US and EU teams - whichever suits you better.
Tell us what you ship, who the users are and whether there are fixed dates. Attach a deck only if it’s already the source of truth - otherwise a short written project brief is faster for everyone.
A senior team member confirms receipt, asks 1–3 questions if needed and proposes either a 30-minute intro call or - if we’re not the right partner - a short, honest answer explaining why. No waiting queues.
We go through goals, constraints and risks. You leave with a clear summary: recommended approach, rough timeline and whether a formal proposal makes sense.
Scope, key dates, deliverables, price, payment schedule and start date. If something is out of scope, we say so clearly - no guesswork.
We schedule the kickoff, set up shared tools (Slack, Linear, Figma as agreed) and start the Listen → Plan phase from the process section on the homepage.
Most UI/UX sprints aim for a first design review within 8–12 business days of kickoff - once the contract is signed, the deposit has arrived and we have access and an agreed project brief.
Review-only or audit packages move faster; work with heavy legal, procurement or multi-team reviews needs more calendar time. We write the target date into the contract so silence never becomes the default uncertainty.
Design is subjective; the project brief shouldn’t be. If the first phase doesn’t meet the success criteria in the contract (audience, constraints, references we discussed), we redo that phase once at no extra charge before the next billable round.
Changing goals mid-project is a scope change, not a free pass - fair to both sides. If we’re still not there after the repeated round, we pause, realign in writing and only then continue billable work.
An honest exit: if the intro call or early research shows we’re not the right partner, we say so directly - we’d rather stop than spend your budget on polite formalities.
Before the kickoff: use our public brief checklist to pull together goals, links, decision makers and success criteria - it’s exactly what we ask for on early calls, so nothing important waits until week three.
The cards on the homepage give a range - starting prices that realistically match what we deliver. The final price always follows the scope in the contract.
Number of pages, user flows, languages and whether it’s a marketing site, an app or both. Larger scope means more design, QA and coordination among decision makers.
CRM, payments, SSO, headless CMS, ERP or custom APIs. Every integration carries risk and a test plan - we spell that out in the contract.
A new brand and UI versus evolving an existing system. “Just ship what we have” costs less than building a component and token system - until it turns out a rework is needed after all.
Parallel sprints, overnight work for a fixed date or a tied-in marketing launch increase the coordination load. We’ll tell you early if a date isn’t realistic.
WCAG level, the need for a VPAT, industry regulations - we expand the test matrix and documentation, not just a “we do our best” line in the footer.
Large approval boards, legal reviews or security questionnaires add calendar time - sometimes a full hour a week for workshop-style status meetings.
Saying “yes” to everything is the fastest route to overbooked calendars and half-done work for clients. Here are the situations where we’ll politely decline - or refer you to a partner who does exactly that.
None of this is a judgment of your business. It’s how we keep the senior team’s attention on projects we can actually deliver.
Client work pays the bills - but we also ship internal tools, site experiments and small helper scripts. This is a simple changelog, not a product roadmap - just proof that we keep building things for ourselves too.
We published a print-ready brief checklist, a clear accessibility and performance bar on the About page, a studio line in the footer (response time + links) and a stricter reference policy for testimonials.
A scope estimate on the pricing page (four questions → a suggested rough scope) and a clearer split between primary and secondary actions in the hero of key pages - contact first, information second.
We added “when we’re not a good fit” and this lab changelog to How we work—fewer surprises before the first call.
An internal Notion checklist that mirrors the proposal sections (integrations, a11y depth, stakeholder shape) so nothing gets skipped by hand at signing time.
A small script + CI hook that flags new components without labels or contrast tokens—experimental; we tune the thresholds per client design system.
Updates are occasional. Day-to-day build context lives in your project channels and kickoff pack—not in a public changelog.
Extended questions that usually land in the same inbox thread before work starts. We’re still happy to clarify details on a call.
Send an inquiryOnce this page has covered the operational side, the intro call can stay focused on the product and metrics.