Most articles about offshore development argue a position. This one doesn't. It's an account of how one founder made the decision, what the working relationship actually looked like week to week, and what he'd tell someone considering the same thing. Thomas Novoszáth had been planning Ostva for years before a single line of code was written. He'd refined the concept, worked through the mechanics, and reached the point every founder eventually reaches: he needed someone to build it. That's where the hard part started.
The real problem wasn't technical
Founders tend to describe their challenge in terms of features. Thomas described his differently. He'd spent years on this idea. Now he had to hand it to strangers.
He evaluated several development companies before choosing us. His criteria weren't unusual, technical capability, pricing, and how the conversations felt, but the weighting was. For a project someone has carried privately for years, the third criterion matters more than most agencies assume. He wasn't shopping for capacity. He was looking for people he'd trust with something he cared about.
We were, in his words, the most convincing on all three counts.
Here's the part worth being direct about: at that moment, neither of us knew whether the working relationship would hold. He was choosing a team in Central Europe for a product aimed at the US market. Every founder in that position has the same unspoken question.
Distance: the concern that didn't materialize
Thomas has since said something we didn't expect and now hear back regularly: working with us felt no different from working with a development shop down the road in Georgia.
That isn't a claim about time zones being irrelevant. It's a claim about availability. Our engineering team is in Budapest, six hours ahead of Eastern Time. In practice this means our afternoon is his morning, and we're reachable for the entire first half of his working day, which is when decisions get made anyway.
The failure mode with distributed teams isn't the clock. It's the response gap: you send a question, and the answer arrives tomorrow. That kills momentum regardless of where anyone sits. Two teams in the same city can have it. Two teams on different continents can avoid it entirely.
Thomas put it plainly: there was no compromise. That's a higher bar than "it worked out," and it's the one we'd want any founder to hold us to.
How the work actually ran
Thomas wanted to be genuinely involved. Not updated, involved. He wanted to understand what was being built and why, and to see it as it took shape rather than at handover.
So the cadence was daily and weekly reporting, regular calls, and test builds pushed to him as often as there was something worth looking at. He could open the product and use it long before it was finished.
This is more demanding than the alternative. It means showing work that isn't polished and explaining decisions while they're still being made. It also means the founder catches misunderstandings in week three instead of week sixteen, which is the entire point.
The other thing it does: it makes the eventual launch unremarkable. When a client has been using the product throughout, there's no dramatic reveal, and no gap between what they imagined and what they got. That gap is where most agency relationships go wrong.
Where we pushed back
The part of this engagement we're proudest of isn't technical.
On several features, we proposed a different approach than the one specified, not because the original was harder to build, but because we thought it would serve the business better. Different mechanics, different sequencing, in a few cases a simpler version of something that had been designed more elaborately than the problem required.
Some of those suggestions were taken. Some weren't. Both outcomes are fine. What matters is that the conversation happened.
A development team that only evaluates requests on feasibility is a contractor. It'll build what you ask for, exactly as asked, and everyone will be technically satisfied when a feature nobody uses ships on time. The more useful question is whether a request makes sense, commercially, and for the person who'll eventually use it.
That's why we look at projects through a business and human lens as well as a technical one. Not because it sounds good on a website, but because the alternative produces expensive software that solves the wrong problem.
Where Ostva is now
Honest answer: earlier than the numbers in most case studies suggest.
The final version took roughly four to six months to build. Testing has been extensive, over a hundred registrations and transactions through the platform, and, more meaningfully, the first organic registrations and transactions have now completed successfully. Real users, no prompting, end-to-end.
That's a milestone, not a growth story. Ostva is preparing for a full marketing push and public launch. We're not going to dress that up as something it isn't.
What we can say is that the platform works, the transaction flow holds under real use, and the relationship has continued past delivery. There have been several rounds of additional development and updates since the build finished, and Thomas is still working with us. For a project that started with a founder cautiously choosing between agencies, that's the outcome that actually means something.
What Thomas says
"Petadev delivered the features and hit the milestones we agreed on. They deliver on time, and when they're behind, they put in the extra hours to catch up. What stands out most is how customer-centric they are." - Thomas Novoszáth - CEO, Ostva LLC
If you're evaluating a development partner
A few things this project reinforced, offered for anyone in the position Thomas was in eighteen months ago.
Test responsiveness before you test capability. Every agency's portfolio looks competent. Fewer are genuinely reachable when you have a question on a Tuesday afternoon. Send a real question during evaluation and see what happens. It predicts the engagement better than the portfolio does.
Ask what they'd change about your plan. A team that agrees with everything either hasn't read it or won't tell you when you're wrong. Neither is what you're paying for.
Insist on working builds, not status reports. Being able to open the product each week is the only reliable way to know whether you're being understood. Screenshots and percentages complete are not the same thing.
Judge the distance question on availability, not geography. The relevant number isn't miles or time zones. It's how long you wait for an answer.
Petadev builds custom mobile and web applications for founders and companies that need software to actually run in production. Our team is in Budapest; Petadev LLC is registered in New York.
Thinking about building something similar?
Tell us what you have in mind and we'll come back with a realistic scope, timeline and budget, usually within two working days. No obligation, and if we think a different approach would serve you better, we'll say so.