How we work

Web development and IT outsourcing

How a project with us actually works

No 30-page onboarding doc. No surprise scope meetings after you pay. This page explains exactly what happens from the first call to delivery — and what to expect from working with Valant Software beyond that.

First call is a real conversation, not a sales pitch
Written scope and timeline before any work starts
Sprint demos so you see progress, not just a final bill
We tell you when something is a bad idea
7steps from first call to live product
1-2 wkssprint cycles with demos at every close
24htypical response time during active projects
100%of clients get written scope before work starts

What working with a small focused development team actually means

We are not a 200-person agency that assigns a junior account manager between you and the developers. When you work with Valant Software, you talk directly to the people writing your code. That changes the speed of decisions, the quality of feedback and the honesty of what you hear. If something does not make sense technically, we say it. If a feature will take three times longer than you think, we say that too. The goal is not to win the proposal. The goal is to build something that works and keep you coming back.

The 7 steps we follow on every project

Every project is different. The process is not. Here is what happens from the first conversation to deployment and support.

01

Discovery call — 30 to 60 minutes

We talk. You explain what you are building, who it is for, what has already been tried and what matters most. We ask questions: deadline pressure, existing tech stack, budget range, team size on your side. We do not pitch during this call. We listen and take notes. At the end you know whether we are a realistic fit or not.

Free, no commitment Zoom, Meet or phone You talk to the actual team
02

Scope document and proposal

After the call we write a scope document. It covers what gets built, what does not, the tech stack we recommend, the team needed and a clear timeline. Pricing is fixed or time-and-material depending on how stable the requirements are — we explain which model makes sense for your case and why.

What it includes Feature list, exclusions, tech stack, team, pricing model, milestones
Typical turnaround 2 to 5 business days after the call, depending on project complexity
What you can do with it Ask questions, push back, request changes — nothing is final until you say so
03

Kickoff and environment setup

Once the proposal is agreed, we set everything up before writing a single feature line. Version control, staging environment, CI/CD pipeline, communication channel, access sharing. You get visibility into the repository from day one if you want it. We also align on how decisions get made during the project — who approves what, how fast, through which channel.

Git repository set up Staging environment live Communication channel agreed
04

Sprint-based development with regular demos

Development runs in 1 to 2 week sprints. Each sprint has a defined scope agreed at the start. At the end of each sprint, you see a working demo — not a status update, actual working features. If something is slower than planned, you hear about it at the sprint close, not in the last week before deadline. This is where most development relationships go wrong, and it is the thing we protect most carefully.

Sprint length 1 week for fast-moving projects, 2 weeks for larger feature sets
What you see Working features in staging, not slides or progress bars
What we flag Blockers, scope drift, underestimated complexity — before they become a problem
05

Review, feedback and QA

Each sprint closes with a structured QA cycle. We test across browsers, devices and edge cases. Bugs get logged, triaged and resolved before the next sprint starts. You give feedback directly — no ticket system maze, just a shared doc or thread. Changes to the original scope get estimated and added to a backlog so nothing gets dropped and nothing gets silently added.

Cross-browser testing Mobile QA Bug triage each sprint Change log maintained
06

Delivery, deployment and handover

When the project is complete, we deploy to production using a checklist. DNS, SSL, caching, backups, monitoring — nothing skipped. We document the system: what it is, how it is structured, what to do if something breaks. If your team needs to maintain it going forward, we walk them through it. You get the code, credentials, documentation and a working product.

What you get Working deployment, codebase, docs, admin access, monitoring setup
What we document Architecture, dependencies, deploy process, critical config, known gotchas
Handover call We walk your team through everything if they are taking it over internally
07

Support, retainer and new features

Most clients do not disappear after delivery. They come back with the next feature, a bug that appeared in production, a performance question or a new project entirely. We offer retainer-based ongoing support, maintenance agreements and continued development. Some clients work with us on one project. Others have been working with us for years. Both is fine — we do not lock anyone in.

Monthly retainer available Maintenance packages New feature development No lock-in

A few things that work differently here

Not better-than-everyone claims. Just the specific ways we are built that affect how the work goes.

No middlemen

You talk to the developers, not an account manager

Questions about technical decisions get answered by the person who made them. There is no translation layer. If you need to change direction, it takes one conversation, not three.

Honest scoping

We tell you when your timeline is not realistic

If what you want takes 10 weeks and you have 4, we say that at the proposal stage. Not on week 8. If we can find a way to cut scope and hit the deadline, we show you that tradeoff too.

Tech advice

We recommend what actually fits, not what we sell best

If WordPress is the right answer for what you are building, we say WordPress. If you need a custom backend, we explain why. We do not have a preferred stack we push regardless of the problem.

Problem-first

We push back when we think something is a bad idea

If a feature will hurt UX, create technical debt or cost five times what it returns, we say it. You still decide. But you decide with the real picture, not a polished version designed to keep you happy in the short term.

Messy codebases

We take over projects other teams left behind

It happens often. The previous agency disappeared, the freelancer went silent, the in-house dev left. We start with a code audit, tell you what you actually have, and give you options from there.

After delivery

We do not vanish when the project is live

Production bugs happen. Hosting questions come up. New requirements appear a month after launch. We stay reachable after delivery and treat ongoing work the same way we treat new projects.

What we build and who usually hires us

Not every project is the right fit. Here is an honest look at what we do well and the type of client this process works best for.

Web development

WordPress sites, custom web apps, landing pages, business sites, API integrations, frontend and backend work. From a single landing page to a full product build.

  • Corporate and business websites
  • E-commerce builds and migrations
  • Custom WordPress development
  • Web application frontends and backends

IT outsourcing

Development capacity for companies without an in-house team, or companies that need to extend what they have. Works well for product companies, startups and agencies that need reliable output.

  • Dedicated development team
  • Staff augmentation
  • Sprint-based delivery for existing products
  • Tech lead and senior dev capacity

CRM and integrations

Connecting systems that do not talk to each other: CRM setup, API integrations, automation pipelines, third-party tool connections, data migration between platforms.

  • CRM implementation and setup
  • API integrations
  • Automation and workflow builds
  • Data migration

When we are probably not the right fit

If you need something built in 48 hours with no calls and no scope discussion, we are not the right team. If you need a full design agency with branding, video production and social media management all under one roof, that is also not us. We are a development team. We do that well. We refer out what we do not. If you are looking for the cheapest possible option and timeline does not matter, there are better choices — we are competitive on price but not the absolute bottom of the market.

How this process compares to the usual agency experience

Not a knock on everyone else. Just an honest comparison of what is different about how we work.

Stage Typical agency experience How we work
First contact Discovery call with a salesperson who hands you to a PM who hands you to a developer You talk to the developer on the first call
Proposal Broad estimate range, vague scope, “we will refine after kickoff” Written scope, defined features, timeline and pricing before work starts
Development updates Monthly status reports, no visible progress until close to deadline Sprint demos every 1 to 2 weeks — working features, not slides
Scope changes Change requests trigger a new contract and a weeks-long delay Changes are logged, estimated and agreed fast — one conversation
Problems Flagged late, often framed as your fault, resolved in the next billing cycle Flagged at the sprint close before they become deadline problems
Delivery You get a link. Good luck with the rest. Deployment, documentation, handover call, access to the team after

Questions people ask before we start

The things that come up on almost every first call, answered honestly.

How long does a typical project take?

Depends on scope. A landing page or simple corporate site: 2 to 4 weeks. A mid-size web application with custom backend and integrations: 6 to 12 weeks. A complex product build: longer. We give a real timeline estimate after scope, not a guess upfront designed to win the proposal.

Fixed price or time and material — which is better?

Fixed price works when the scope is clear and you both agree it will not move much. Time and material works better when you are building a product and requirements will evolve. We recommend the model that protects you financially for your specific case, not the one that is better for us.

How do we communicate during the project?

Slack, Teams or Telegram — whatever you already use. Daily async updates when things are moving. Sprint demos every week or two. A dedicated channel where questions get answered same day during active development. No email chains with a three-day response window.

What if my requirements change mid-project?

We log it, estimate the impact on scope and timeline, and agree before moving forward. Nothing gets added silently. Nothing gets delayed without explanation. Change is normal in development — the problem is when teams pretend it is not happening and then bill you for it at the end.

Can you take over a project someone else started?

Yes, this is one of the more common things we do. We start with a code audit — usually takes a few days. We document what exists and flag the real risks honestly. Some codebases are solid. Some need a partial rewrite. Some need to be scrapped. We tell you which, and why, before any decision is made.

Do you work with clients in other time zones?

Yes. We have clients in Western Europe, the UK, the US and the Middle East. Async-first communication handles most of it well. For real-time overlap we agree a daily window that works for both sides — no one needs to be on calls at 11pm every day for the project to run well.

Ready to talk through your project?

If you know what you need — give us a quick brief and we will come back with honest questions and a timeline. If you are still figuring out what makes sense technically, that is what the first call is for. Either way, the first conversation is free and there is no obligation to move forward.