Skip to content
How we work

A delivery process built so you always know where things stand

Most offshore projects fail on communication, not on code. This is exactly how we run an engagement — read it before you commit, and hold us to it afterwards.

Reply time
within 1 business day
Working hours
4+ hrs US overlap
Confidentiality
NDA before details
Ownership
Your repo, your IP
The process

From first email to post-launch support

Six steps. Each one ends with something concrete you can read, click or keep.

  1. 1

    Share your requirement

    Day 0

    You send us what you need — a detailed spec, a rough idea, or a screenshot of a competitor. All three are fine.

    • Submit the form or email us; no sales gatekeeping call required first
    • We read it and come back with clarifying questions, not a generic brochure
    • NDA signed before you share anything sensitive, if you want one
    You get:A reply from an engineer, within one business day
  2. 2

    Scoping call & written estimate

    Days 1–4

    A 45-minute call to understand the business goal, then a written breakdown of scope, cost and timeline.

    • We map requirements into modules, each separately estimated
    • Risks and unknowns are called out explicitly, with how we would de-risk them
    • You get a fixed price, a dedicated team rate, or both — whichever fits
    You get:A proposal you can compare line by line against other quotes
  3. 3

    Kickoff & architecture

    Week 1

    Contracts signed, environments created, and the technical foundation agreed before feature work begins.

    • Repository set up in your Git organization, with CI from the first commit
    • Architecture and data model documented and reviewed with you
    • Sprint plan agreed, with the first demo date already on the calendar
    You get:Architecture document, sprint plan, and access to everything we touch
  4. 4

    Build in two-week sprints

    Ongoing

    Working software every sprint on a staging URL you can click through yourself.

    • Daily written standups in your Slack, plus live overlap hours
    • A demo and a deployed staging build at the end of every sprint
    • Code review and automated tests on every pull request
    • Scope changes handled openly: we show the cost before it is committed
    You get:A staging environment that is always up to date
  5. 5

    QA, hardening & launch

    Final 2–3 weeks

    Cross-browser and device testing, performance, security review, then a controlled release.

    • Functional QA against the agreed acceptance criteria
    • Performance budget and Core Web Vitals checked on real devices
    • Security review: authentication, access control, dependency audit
    • Production deployment, monitoring and rollback plan in place
    You get:A live product, plus the runbook for operating it
  6. 6

    Support & iteration

    Post-launch

    Stay on a retainer for fixes and features, or take everything in-house with a documented handover.

    • Defined response times for production issues
    • Dependency and security updates kept current
    • Monthly allocation of hours for improvements
    • Full handover documentation, whenever you want it
    You get:A system that keeps working after we stop touching it
Communication

How we stay in sync across time zones

The rituals that make a remote team feel like the one down the hall.

Daily written standup

Posted in your Slack every working day: what shipped, what is next, what is blocked. Readable in 30 seconds, and it means progress never depends on catching someone online.

Live overlap hours

Our team works a shifted schedule that overlaps your morning, so questions get answered in the same conversation rather than the next day.

Sprint demo every two weeks

A recorded walkthrough of working software on a staging URL you can click through yourself. You never have to take progress on trust.

Your tracker, your repo

We work in your Jira, Linear or GitHub Projects — not a private board you have to ask about. Every ticket and commit is visible to you in real time.

Quality

What “done” means here

These are the gates every piece of work passes before we call it finished.

Code review on every change

No commit reaches your main branch without a second engineer reading it. Your own developers can be reviewers too if you want that oversight.

Automated tests and CI

A pipeline that runs on every pull request: type checks, linting, unit and integration tests. A red build blocks the merge.

Performance budgets

Core Web Vitals targets agreed at kickoff and measured on real devices before launch — not discovered when your ranking drops.

Security review before release

Authentication and access control tested, dependencies audited, secrets checked out of source control, and error handling that does not leak internals.

Accessibility as a default

WCAG 2.2 AA as the working standard: keyboard navigation, focus states, contrast and screen-reader labelling built in rather than retrofitted.

Documentation as a deliverable

Architecture notes, environment setup and a runbook — written as we go, so the handover is not a scramble at the end.

Commercials

Three ways to engage

Choose based on how well-defined your scope is, not on which sounds cheapest — a fixed price on a vague scope is the most expensive option there is.

Fixed scope, fixed price

Well-defined projects with a clear finish line

We scope the work in detail up front and commit to a price and a date. Best when you know what you want built and need budget certainty to get it approved.

  • Written scope with per-module estimates
  • Fixed price and delivery date
  • Milestone-based payments
  • Change requests priced before they are started
  • 30 days of post-launch bug fixes included
Billing
Milestone payments
Minimum
Project-based
Discuss this model
Most popular

Dedicated team

Ongoing product work where scope evolves

A named team works only on your product, effectively as your remote engineering department. You direct priorities sprint by sprint without renegotiating a contract each time.

  • Named engineers, designers and QA — no silent substitutions
  • You set sprint priorities
  • Direct Slack access to every team member
  • Monthly rolling contract
  • Scale the team up or down with 30 days' notice
Billing
Monthly per person
Minimum
3 months
Discuss this model

Time & materials

Support, maintenance and unpredictable work

Hourly billing against a monthly cap you set. Best for maintaining an existing system, working through a backlog, or handling work you cannot estimate in advance.

  • Billed in 15-minute increments
  • Monthly hour cap you control
  • Itemized timesheet with every invoice
  • No minimum monthly usage
  • Defined response times for production issues
Billing
Hourly, invoiced monthly
Minimum
None
Discuss this model
Guarantees

What we commit to, in writing

Every one of these is a term we will put in the contract.

Real overlap with your workday

Our team works a shifted schedule so you get live conversation during your morning, not a 12-hour round trip on every question. Standups are also written down, so nothing depends on catching someone online.

You own everything from day one

Code lands in your Git organization, deployments run in your cloud accounts, and app stores stay under your company. IP assignment is in the contract, so changing vendors later never costs you the product.

Working software every two weeks

Every sprint ends with a deployed staging build and a demo. You never have to take progress on faith or wait until the end to discover it was built wrong.

The people you meet are the people who build it

No bait-and-switch between the pitch and the project. You are introduced to the actual engineers, and we do not swap them out mid-project without telling you.

NDA and security first

NDA signed before you share anything confidential. Least-privilege access, secrets kept out of source control, dependency audits on every release, and a documented offboarding when we finish.

An honest exit

Documentation, runbooks and a handover session are part of delivery, not an upsell. If your in-house team is ready to take over, we help you make that transition cleanly.

Questions

Working with us

How do we start working together?

Send your requirement through the form — a detailed spec, a rough paragraph, or a link to something similar all work. You get a reply from an engineer within one business day, then a 45-minute scoping call, then a written estimate broken down by module. There is no obligation at any of those steps.

What if I don't know exactly what I need yet?

That is normal and it is not a problem. Describe the business problem instead of the solution and we will help shape the scope. For larger unknowns we run a short paid discovery that produces a specification and an estimate you own — usable even if you take it to a different vendor.

How do you handle confidentiality?

We sign your NDA before you share anything sensitive, or provide ours if you prefer. Access follows least privilege, credentials never live in source control, and every account we were given is revoked at the end of the engagement.

How do payments work for US clients?

We invoice in USD and accept ACH, wire and card. Fixed-scope projects are billed against milestones; dedicated teams and retainers are invoiced monthly. Payment terms are net 15 by default.

What does communication look like day to day?

A shared Slack channel with your team, a written standup every working day, and a live demo at the end of each two-week sprint. Tickets live in your project tracker, so you can see status without asking anyone.

Who owns the code and the intellectual property?

You do, in full. Work is committed to your repository from the first sprint and IP assignment is written into the contract — you are never dependent on us to keep running what we built.

What if we need to stop or pause the project?

Dedicated team engagements can be paused or ended with 30 days' notice, and time-and-materials work has no minimum at all. Whenever you stop, you receive the handover documentation. We would rather you leave cleanly than feel trapped.

Do you work with existing in-house teams?

Frequently. We join your rituals, your repository and your review process rather than running a separate parallel project. A common split is that your team owns domain logic while we add capacity on a specific surface.

Sound like a fit?

Send your requirement. Worst case, you get a free scope breakdown and an honest opinion on whether the project is worth doing.

Reply time
within 1 business day
Prefer email?
sales@tooltar.com