Custom software

Free consultation Projects

We design a custom system around the way your team actually works, and we carry it through to delivery together with a technology partner matched to the stack. The repository, the documentation and the rights to the code sit on your side from the first commit.

We have worked with leading companies and startups

Challenges

Three situations where a custom system beats an off-the-shelf one

Not sure your case needs a system written from scratch at all? Book a consultation - if configuring an existing tool or a no-code build comes out cheaper, we will say so plainly.

  • „The process does not fit an off-the-shelf tool”

    The team bought a subscription and then wrapped it in spreadsheets, macros and manual re-keying, because the tool does not know your rules. A custom system starts to pay off at the moment when maintaining the workarounds costs more than the licence itself.

  • „Operational work has scattered across several systems”

    The order lives in one place, the settlement in another, the customer correspondence in a third, and a coherent picture only forms in someone's head and in a file on a drive. That is when you build a layer that ties data and decisions together instead of adding a fourth tool.

  • „The software is the product, not an internal cost”

    You sell access to the system, so the interface is what the customer pays for, not a backdrop for your team's work. Design then has to run ahead of code, because fixing the data model after launch costs many times more than fixing a wireframe before it.

Who it is for

Who we build custom systems for

  • Companies that have outgrown spreadsheets and an inbox

    The process works because a few people remember where everything sits and who to pass a case to next - and every holiday and every new hire shows how expensive that memory is. We start by writing down rules that were never written, and the system grows out of those.

  • Product teams that sell access to a system

    Here the interface is the product, so every unclear field in a form comes back as a support ticket and as an argument at renewal. We design views for the real roles on the customer's side, not for a demo, and we test them with users before implementation.

  • Software houses missing the design layer

    You have developers and a client, and what is missing is someone to turn requirements conversations into screens and acceptance criteria. We then work under your brand, inside your process, handing over material ready for estimation rather than a deck of recommendations.

  • IT teams maintaining a system written years ago

    The application carries daily work, the documentation stopped in its second year, and the author left the company long ago. We reconstruct the working process from the system itself and from conversations with users, then design the replacement in parts, with no single day when everything stops at once.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

How our approach differs

  • First we check whether this system should be written at all

    The workshop ends with a recommendation, and that recommendation is sometimes negative - occasionally the process closes with a configuration of a tool you already own, or a no-code build with migration later. We would rather lose the project at that stage than deliver a system that sits next to the old spreadsheet a year on.

  • The design is a contract, not inspiration for a developer

    Every screen has described states, validation and permissions, and accepting a release means walking through those criteria on the test environment. Conformance between the build and the design is then something you verify item by item, not a claim in a proposal.

  • The code is written by a builder matched to the technology, the oversight stays with us

    We do not pretend to run our own engineering department - we match a partner to the stack and to the scale of the system, and we sit on your side of the table during pricing, acceptance and scope disputes. If you have developers in house, all the better - we work with them off the same specification.

  • We leave the project in a state where we can be replaced

    The repository, the architecture documentation, the component library and the process map stay with you, in a format the next team can read. Locking a client to a vendor is a business model in this industry - for us it is simply a defect in the project.

Process

Five steps from the workshop to the first release in production

  1. Week 1–2

    Workshop and process map

    Two or three sessions with people from different roles - who opens a case, who approves it, where it stalls. The result is a process map in a notation both your team and a developer can read, plus a list of rules nobody had written down before.

  2. Week 2–4

    Scope, integrations and the split into releases

    We settle what goes into the first release and what waits, and match it against the systems already running at your end. Every integration gets a described data direction and an owner on the client side, so it does not turn into a surprise mid-build.

  3. Week 3–8

    Screen design and component library

    We design views for every role, starting with the ones where the team spends the most time - filtered lists, forms and detail views. The clickable prototype gets checked with the operators before anything goes to implementation.

  4. Week 7–9

    Build-ready specification and choosing the builder

    Behaviours, permissions and edge cases are written as acceptance criteria pinned to screens. Your team or a technology partner prices the work on that basis - and the quotes are comparable, because they all cover the same scope.

  5. Week 9–20

    Delivery, reviews and operational launch

    We accept releases on the test environment, screen by screen, against the specification. After launch we stay with the team through the first weeks of work on live data, when the cases a design cannot show start to surface.

Deliverables

Three parts of the build. Not a design handed over for pricing

  • A process map and the scope of the first release

    Conversations with the people who run the process today, and a walk through the spreadsheets, inboxes and panels where the work really happens. What stays is a map of operations, written-down business rules, a register of integrations and a scope split into releases - with "later" made explicit.

  • Screens for every role and a component library

    A full set of views split by role, with empty states, validation errors and bulk operations - not just the happy path. Components are built as a named library with tokens, so a developer gets elements to assemble rather than pictures to reproduce.

  • A build-ready specification and conformance reviews

    Behaviours, validation, permissions and edge cases written against specific screens, plus a review of every release on the test environment. We run those with your team or with our technology partner - depending on who writes the code.

Toolkit

What we apply

Standards chosen so that design and code speak one language - from process notation, through tokens, to acceptance criteria written in a way that can actually be checked on a test environment.

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • BPMN for process maps and decision rules
  • User stories with acceptance criteria
  • W3C design tokens and a named component library
  • WCAG 2.2 AA for operational interfaces
  • API contracts described in OpenAPI
  • Roles and permissions enforced server-side
  • A test environment on production-like data

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Work from the areas we build systems for

A selection of projects from the product types where custom software comes up most often for us - web applications, operational panels and sales systems. Internal deployments we show by name during a consultation.

Projects

Outcomes

What you get, on what timeline and how you verify it

  • 10–20 weeks

    From workshop to the first release in production - the lower bound covers one process and one role, the upper one a system with integrations and several permission levels

  • 1 release

    We close the first scope so it can be folded into operational work, instead of holding the launch back for a complete set of features

  • WCAG 2.2 AA

    The public W3C accessibility standard we design forms, tables and bulk-operation views against

  • Your repository

    Where the code and documentation sit after delivery - no licence for your own system and no dependence on us for the changes that follow

The timelines come from the schedule described above on this page, WCAG 2.2 AA is a public W3C standard, and the rights to the code and documentation are governed by the delivery contract. We do not publish averaged savings or metrics from client systems - those numbers belong to them, so we show them by name during a consultation.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long delivery takes and what drives the quote

10–20 weeks

Ten weeks covers one process, one role and an integration with a single system - a scope you can launch and verify in real work. Twenty weeks and beyond is a system with several permission levels, data migration and the replacement of a tool that runs operations today; we then split the work into releases so the first one enters use before the project ends.

  • The number of processes and roles the system covers in the first release

  • The number and type of integrations with tools already running at your end

  • How much of the business rules are written down and how much lives in people's heads

  • The scope of data migration from current tools and the state of that data

  • Requirements around permissions, audit trails and personal data processing

FAQ

Questions that come up most often

How much does custom software cost?

We quote every case individually, because the entry threshold says little about your specific build - the cost depends on the number of processes and roles in the first release, the number of integrations with tools already running at your end, the state and scope of the data to migrate, the requirements around permissions and audit trails, and whether the code is written by your team or by our technology partner. The biggest single factor is how much of your business rules are already written down and how much has to be reconstructed from conversations. You get an initial scope and a range after the workshop, and a reply to your enquiry within 48 hours.

Are you a software house?

No, and we do not pretend to be one. We are a UX agency - process analysis, interface design, the build-ready specification and oversight of conformance between the build and the design sit on our side. The code is written by your team or by a technology partner matched to the stack and the scale of the system, and we stay on your side of the table during acceptance.

Where do the developers come from and who talks to them?

We match the partner to the technology and the size of the system, after the scope is set - not the other way round. You can contract the builder directly or contract us as the main supplier, and in both variants the specification, the schedule and the acceptance criteria are identical. Day-to-day communication we run together, in your channel and on your task board.

Who owns the code and the documentation after delivery?

You do, from the first commit. The repository sits on your account, the architecture documentation, the component library and the process map travel with the system, and the transfer of economic copyright is governed by the delivery contract. We do not sell licences for a system built with your money and we do not hold the keys to your infrastructure.

When is an off-the-shelf tool or no-code cheaper?

Whenever the process can be described in standard terms - simple CRMs, document routing, bookings, a site with a form. Configuring a tool or a no-code build then closes the subject faster and for less, and a custom system waits for the moment you outgrow it. We will say so at the workshop, even when it means no project on our side.

What if we already have a system and want to replace it?

We start by reconstructing what works today - from the system itself and from conversations with the people who use it, because the documentation usually stopped years ago. We design the replacement in parts, module by module, with the old and the new system running side by side through a transition period. There is then no single day when the whole operation moves across at once.

How do you make sure the build matches the design?

Every screen has described states, validation, permissions and edge cases written as acceptance criteria, and accepting a release means walking through that list on the test environment. Discrepancies go back to the builder as specific items, not as a general remark that "it looks different from Figma".

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation