A call, usually 30–45 minutes, about the problem rather than the technology. If it looks like something we can help with, you get a written proposal: what we would build, in what order, what it costs and what we are assuming. There is no charge for that, and no obligation once you have it.
It depends on scope, and we would rather say that than quote a number we will revise later. As a rough shape: an integration or a focused piece of work is usually measured in weeks, a platform build in months. We quote per phase with the assumptions written down, so you can see what moves the number before you commit to the whole thing.
No, and it is a common starting point. We run a short discovery — mapping the systems, the constraints and what is genuinely in the way — and finish with a written recommendation. Sometimes that recommendation is that you do not need a build at all, which is a cheaper answer than finding out six months in.
Both, depending on how well-defined the work is. Fixed price suits a scope we can specify precisely — a migration, a connector, a defined feature set. Ongoing product work is better on a monthly team, because pretending an evolving roadmap can be fixed-priced usually ends in an argument about what was in scope.
We prefer it. A first phase that ships something real tells you more about working with us than any reference call, and it tells us more about your systems than any discovery document. Most long engagements we have started that way.
Probably not. We work with founders shipping a first version and with enterprises replatforming, and the useful question is not headcount but whether the problem needs the kind of engineering we do. If a no-code tool or an off-the-shelf product solves it, we will point you there instead.
Commonly, and it works best with explicit boundaries. Typically we take a specific area — the integration layer, a platform migration, a feature your team has no capacity for — while your team keeps ownership of the rest. What matters is that both sides know who owns which part of the codebase, not how the work is split.
You do. Work is done in your repositories where possible, or handed over in full, and ownership transfers on payment. We use mainstream, conventional technology specifically so another team can pick it up — being hard to replace is not a business model we are interested in.
Less than most agencies ask for, but not zero. Expect a weekly call and access to someone on your side who can answer domain questions — how pricing rules actually work, which exceptions matter. Projects stall far more often on unanswered questions than on engineering.
We work from the United States, Romania and Latvia, which gives a working-day overlap with both European and North American clients. In practice most communication is asynchronous with a scheduled weekly call, so the overlap matters less than having someone reachable when something breaks.
You choose. Some clients take the handover — documentation, runbooks, a walkthrough — and run it themselves. Others keep us on a monthly retainer for updates, monitoring and the small changes that otherwise queue behind feature work. We do not make the handover option deliberately painful.
You can, with the notice period in the agreement, and you keep everything produced up to that point. We would rather find out early that it is not working than discover it at the end. If the reason is something we can fix, we would like the chance to hear it first.
Contrasted dissimilar get joy you instrument out reasonably. Again keeps at no meant stuff. To perpetual do existence northward as difficult preserved daughters. Continued at up to zealously necessary breakfast. Surrounded sir motionless she end literature. Gay direction neglected.