DEV Community: Revin

High test coverage is where production bugs hide best

Revin — Fri, 07 Aug 2026 16:44:43 +0000

Originally published on the Revin blog.

A founder in fintech texted me a screenshot at 11pm on a Thursday. It was his vendor's test report: 92% coverage, all green, the kind of badge you are proud to pin to the README. In the same screenshot, open in another tab, his product's checkout screen frozen. He is not a Revin client. He had come to me through a referral, wanting a second opinion before he renewed the contract with the shop that built the thing.

His question was honest and uncomfortable: how does 92% coverage let the checkout go down? The answer fits in one line, and it is behind half the surprises I see in production. Test coverage does not measure whether your software works. It measures how many lines ran while the tests executed. Those are different things, and the gap between them is where the bug hides.

A test can walk through this entire component, log the value to the console, and never once check whether it is right.

What test coverage actually counts

Coverage is an execution metric. The tool instruments your code, runs your suite, and flags every line, branch, and function touched at least once. Then it divides what was touched by the total and hands you a percentage. It is genuinely good for one thing: finding code no test comes near. A block sitting at 0% is a real warning.

The problem is what it ignores. The metric records that the line ran. Whether anyone checked the result of that line, it has no idea. A test that calls calculateInterest(balance) and never inspects the return marks the function covered all the same. The function ran. The value it produced went unreviewed. On the dashboard, that green looks identical to a test that checks the number to the cent.

That is roughly what we found in the fintech suite. Plenty of tests exercised the code and stopped there, never asking whether the result matched what it should be.

How does a test run, pass, and verify nothing?

There are three common ways for a test to go hollow. None of them shows up in the coverage percentage:

Assertion-free tests: they call the function and use no expect at all. If nothing throws, they pass. The line is covered; the behavior is not.
Over-mocking: the test stubs so many dependencies that it ends up checking its own mock. You program the answer and, three lines later, assert that the answer is the one you programmed.
Snapshots on autopilot: the test compares output against a saved snapshot. When it breaks, plenty of people just run the update, the snapshot becomes the new truth, and the test goes green again with nobody reading the diff.

All three inflate coverage and hold nothing up. Because the number climbs, everyone feels safer. The vendor included, now quoting that 92% as if a percentage were the same thing as quality.

Picking up a test and asking 'what happens if I break this line on purpose?' tells you more than any percentage in the report.

The number the body shop loves to put on a slide

Coverage turned into a sales metric. It climbs easily, because writing an assertion-free test is fast. It fits in a round number. And it impresses anyone who does not read code. For a shop that bills by delivery, it is the perfect indicator: it grows almost on its own, and the client has no way to challenge it from the outside.

The incentive is crooked. When the contract pays for a feature shipped with tests, the vendor optimizes to hit the percentage. Preventing the production incident is separate work, duller and pricier, that nobody is paying for out loud. It is not that they are lying. They are measuring the easy thing and charging for it.

On a senior squad, a test is reviewed like production code. A pull request that adds an assertion-free test does not pass review: it comes back with a single question, what is this guaranteeing? That is how we look after client suites at Revin, and it is what separates coverage that protects you from coverage that just decorates you. If nobody has ever reviewed your tests with that kind of rigor, start with an honest audit of what is there today.

🧬 Mutation testing: who tests your tests?

There is an old, underused technique aimed squarely at this blind spot: mutation testing. The idea is almost cruel. A tool takes your code and plants bugs on purpose: it flips a > into >=, negates a condition, deletes a line, or turns a + into a -. Each broken version is a mutant, and your whole suite runs against every one of them.

The read is blunt. If the code was broken and no test complained, that test was protecting nothing: the mutant survived. What matters stops being how many lines you cover and becomes how many of those planted bugs your suite actually kills. Tools like Stryker in the JavaScript and TypeScript world, and PIT in Java, do exactly this and give you back a mutation score.

We ran Stryker on that 92% suite. The mutation score came back at 41%. Put plainly: more than half the bugs we planted on purpose sailed straight past the green tests. That number moves with the tool and with what you ask it to mutate, I will grant that. I do not treat 41% as a law of physics. But even shaving off a generous margin, the conclusion holds: the comfortable suite covered plenty and, when it came to catching a real bug, let it through. That is the kind of read we do in the first days with a client, and a few of them become a published case later.

The green that counts is the one you can break

If you are a founder, do not ask for the coverage percentage. It will come back high and tell you nothing. Ask your team or your vendor something else: what happens to the suite if someone breaks a business rule on purpose? If the answer is silence, or a 'we trust the ninety-something percent,' you already have your diagnosis.

I will be fair. Not every project needs this. A five-page marketing site is never going to set up mutation testing, and that is perfectly fine: high coverage already does the job there, and hiring a senior squad would be a waste of your money. But anything that touches money, sensitive data, or a flow that takes the whole operation down when it fails, the pretty number on its own is theater.

The fintech founder did not switch vendors out of anger. He switched because, for the first time, someone sat down with him and showed him in plain terms how much that comfortable suite was really defending his product. It was very little. If you suspect your own coverage is closer to decoration, the first move is to look hard at what your suite actually guarantees today, and that audit fits inside one conversation.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

Security isn't a feature you bolt on. It's how the team works.

Revin — Thu, 06 Aug 2026 15:10:19 +0000

Originally published on the Revin blog.

I read software development proposals almost every week. Part of my job at Revin is to look at what a founder is about to sign before they sign it. And there is one line that shows up so often it has become a running joke on our side. It turns up in fintech, in healthtech, in marketplaces, regardless of the sector. Always somewhere in the middle of the document, in the calm tone of someone simply sorting priorities: "we'll handle security in a later phase".

A later phase sounds perfectly reasonable when you are racing to launch and the budget is tight. The trouble is that this "later" almost never becomes a real date on the calendar. It becomes an item that slides down the backlog every sprint, pushed aside by something that feels more urgent. And almost everything feels more urgent than security, right up until the day it doesn't.

This piece is for whoever is about to hire the people who build their software, and wants to know in advance whether security is something that team does or something it merely promises to do. Those are very different things, and the difference is visible before you sign.

Where security shows up, or doesn't: less in a contract clause, more in the lines the team writes every single day.

The "later" that never comes

Why is security always the easiest thing to postpone? Because it is invisible while it works. Nobody opens the app in the morning and thinks "great, my data didn't leak today". A new feature gets a demo, a screenshot in Slack, a round of applause from the board. Security done well shows up nowhere, until the day its absence becomes the only thing anyone can see.

Then there is the vendor incentive nobody mentions in the room. Whoever gets paid for visible output optimizes for visible output. A body shop billing by the screen has no reason to spend three days reviewing an access rule the client does not even know exists. It is not bad faith. It is the contract spelling out what matters, and security was not written into it.

I have seen exceptions, of course. The careful freelancer who does the right thing without being asked does exist. You just have no way of knowing which one you have got before you hire, and betting your customers' database on "maybe this one is a good one" tends to get expensive.

Where the gap shows, and it's never a movie hack

When a system leaks, the real story is almost never the one from the films. There is rarely a hooded hacker breaking encryption at three in the morning. What is there is a lot more boring than that.

Earlier this year Revin was brought in to review the code of a marketplace with around 20,000 active users. Lean team, built entirely by two freelancers in a hurry. Within half a day of reading we found the usual suspect: the payment API key written straight into the code, in plain text, in a commit from 2023. It was sitting in the Git history, visible to anyone who cloned the repo. Nobody had rotated it because nobody remembered it was there.

That kind of hole tends to live in four places:

A secret in the code: API keys, database passwords and tokens committed in plain text.
Access nobody revokes: the freelancer left eight months ago and his production credential is still alive.
Permissions that are far too broad: everyone became an admin because setting up proper roles was a hassle at the time.
A dependency frozen in time: a library with a known flaw for two years that nobody updated because it was working.

None of these needs an evil genius to exploit. It needs a curious intern, a resentful former contractor, or just a bad day. And they all share the same root: they appeared because nobody on the team was in the habit of looking.

Finding this early is half the battle. The Diagnostic Sprint grew out of roughly that: two weeks, code on the table, and an honest picture of what is exposed handed back to you while fixing it is still cheap.

Real security doesn't live in an annual report. It lives in the code review that happens before the merge.

Security is code review, not an audit

The difference between a team that has security and one that only promises it is not an expensive tool or a certificate framed on the wall. It is a habit, and that habit is visible in the working rhythm of whoever you hired.

On a senior squad, security is not a stage that happens at the end of the project. It is a lens that stays on the whole time. When someone opens a pull request, the reviewer does not only check whether the code works. They check whether the new endpoint verifies permissions, whether some sensitive field is being written to a log by accident, whether that query accepts a parameter it should not. Least privilege stops being a nice phrase in a policy doc and becomes the default way to create access: it starts closed and opens only as much as needed.

That is how it works on Revin's squads, and not out of any special virtue on our part. It is simply cheaper. Reviewing a permission inside the pull request costs ten minutes of whoever is on review duty. Discovering the wrong permission after it has already leaked costs you the client.

This is not the same as chasing SOC 2

A caveat here, because security as a habit keeps getting confused with security as paperwork. They are not the same thing. You don't need SOC 2 in year one, nor a pricey quarterly pentest, and you certainly don't need a CISO before you have product-market fit. Chasing compliance too early is usually money down the drain, something we argued in why a year-one startup shouldn't chase SOC 2.

A certificate is something you buy off the shelf. The habit comes from the team itself: either they already work this way, or they will learn it on your project, on your timeline, with your data. When it is already baked into how people write code, it costs very little.

So next time a proposal lands in your lap and your eyes catch that line, "we'll handle security later", be suspicious of the verb. The question that matters is not when it will get done, it is whether that team already does it by default. A team that treats security as a habit does not even write the sentence, because for them there is no later phase: it has been part of the work since the first commit. Whoever promises it for later is telling you, in plain words, that the habit is not there. You can hire them anyway, but at least you heard the warning.

In the end, security is less about what you buy and more about who you let into your code. If you want to see how an embedded squad handles this day to day, or to read about the other vectors that show up once AI enters the workflow, just book a call with us.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

It was fast in the demo. Then the data grew.

Revin — Wed, 05 Aug 2026 14:50:55 +0000

Originally published on the Revin blog.

There is a sentence I hear almost every week, always in the same surprised tone: "at launch the app flew, now it hangs." The last time, it came from a niche e-commerce shop, a team of about 40, that came to Revin for a second opinion on a product another vendor had built. The orders screen, which used to open in a blink when the site went live, was taking 14 seconds to load. Nobody had touched the code in months. The only thing that changed was the size of the database.

The easy read is to blame the infrastructure. "We need a bigger server," "Postgres can't keep up." It almost never is. Most times Revin pops the hood on an app like this, the server is bored, sitting at 12% CPU, waiting on code that talks to the database the wrong way.

And the nasty part is that this defect is invisible exactly when you would most want to catch it: on delivery day, with test data, everything runs beautifully.

A chart on a laptop screen: queries that were flat at launch turn into spikes as the data grows.

Why the demo never shows this

In the demo, the database has 200 rows. Maybe 500. With 500 rows, everything is fast. You can write the laziest query in the world, without a single index, and the database scans the whole table in under a millisecond and nobody notices.

The classic case is what the Revin engineers call the N+1 problem. A screen lists 50 orders and, for each order, the code fires a fresh query to fetch the customer. Then another for the line items. Your 50 orders become 101 round trips to the database, sometimes 150. With the test seed it happens too fast to notice. In production, with a full table and the network in the middle, every round trip costs you. Multiply.

The ORM helps hide the crime. An innocent line that reads like "grab this order's customer" is, in reality, a database query fired inside a loop. The dev who wrote it never sees the query. The founder who approved the demo, even less so.

The bill that grows with your success

Here is the cruel part. While the product has not taken off, nobody feels a thing. The database is small, the bad queries slip by unnoticed, and the vendor hands everything over "on time, working." The bill for the bad design only arrives once the product starts to succeed.

At that e-commerce shop I mentioned, the orders screen was firing more than 1,200 queries to render a single page. With 300 orders early on, nobody complained. Once the catalog grew and they crossed 38,000 orders, that same screen turned into the 14-second nightmare and support started hearing "the site is down" all day long. An honest caveat about that number: the people who call me are already having their worst day, so my sample is biased toward disaster. Even so, the pattern repeats so often it reads like a script.

In other words: the real test of your software is not the launch. It is month six, when it succeeded enough to get slow.

A data-center aisle: most of the time the problem is not here, it is in how the code asks for the data.

If your busiest screen started dragging as the data grew, it is worth a technical diagnosis before you buy a bigger server. A Revin Diagnostic Sprint is a good place to start.

What a senior squad checks before you even complain

I asked the engineers at Revin what they look for in these cases, and the answer was almost disappointing in how basic it is. No magic. Just the discipline most teams skip because it takes effort and never shows up in a demo.

Run EXPLAIN ANALYZE on the queries behind your busiest screens. It is the command that shows, with no guesswork, whether the database is scanning the whole table or using an index.
Turn on query logging in development to hunt for N+1. If a screen fires 80 queries to render one list, something is wrong right there.
Add an index where the lookup hurts, and only where it hurts. Too many indexes also cost you on writes and storage.
Test with production-scale volume, not the 200-row seed. Fill the database with a million fake records and see what breaks before your customer does.
Set a budget: no critical screen goes over X queries or Y milliseconds. And measure it every release, not once.

None of this is rocket science. But notice that all of it costs effort today to head off a problem that only shows up six months from now, long after the cheap vendor cashed the check and vanished. That is why, at Revin, database performance goes into the definition of done from the first sprint. A senior embedded squad pays that bill while it is still cheap.

Want to see how this looks in a real project? Some of our cases show the before and after of exactly this kind of bottleneck.

The index that was worth 9 seconds

Back to the e-commerce shop. The most impactful fix Revin made in the first week was almost embarrassingly simple: a missing index on a date column. A query that took 9 seconds started answering in 40 milliseconds. There was no rewrite and no new server. There was someone reading the EXPLAIN nobody had bothered to read.

To be fair to the other side: if you have a three-screen MVP still hunting for its first ten customers, tuning indexes now is a waste. At that stage your challenge is finding someone who will pay; scaling a database is a problem for much later. Hire someone fast, ship it ugly, keep moving. The index becomes urgent the day the product starts working, and that is exactly the day the cheap vendor never planned for.

If your system is already past that stage and has started to drag, do not swap servers in the dark. Book a call with Revin and we will look at what the database is trying to tell you.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

Why EU startups are trading Poland/Romania for Brazil in 2026

Revin — Tue, 04 Aug 2026 12:37:51 +0000

Originally published on the revin.com.br blog.

For a decade, the default nearshore for European startups was Poland (scale), Romania (cost), or Ukraine (deep cost). In 2026, that equation changed — and Brazil entered the radar as a serious alternative. Not by fashion; by numbers.

Revin has operated Brazilian squads with EU clients since 2024 and observed 5 factors that reorganized the European nearshore choice. For EU startups in 2026, Brazil wins on 3 of 5; ties on 1; loses on 1 (timezone with late-day clients). For most scenarios, the total math closed in Brazil's favor.

For founders and CTOs in Lisbon, Berlin, Amsterdam, Paris, Stockholm, Madrid evaluating nearshore in 2026 — and who want data, not pitch.

Cost, timezone, seniority, culture, and compliance aligned on one side in 2026

📊 The 5 factors that changed

Factor 1 — Cost: Poland got expensive, Brazil still competes

Senior dev Poland: USD 75-100/h in 2026. Senior dev Brazil: USD 50-75/h. For a 5-person squad on a 12-month project, direct difference of USD 150k-300k. The additional coordination cost of Brazil (1-2h extra timezone for Western Europe clients) doesn't consume that delta.

Factor 2 — Seniority: Romania thinned; Brazil has active pool

Romania lost much of the senior pool to German, Swiss, and North American companies on premium remote contracts. Brazil had the inverse trajectory: the fintech/SaaS ecosystem of the last 5 years built a large senior layer, still available for nearshore.

Factor 3 — Timezone: Brazil has 4-6h synchronous with Western Europe

Lisbon, Madrid, Paris have 5-6h overlap with Brazilian business hours. Berlin, Amsterdam have 4-5h. Enough for technical discussion in calls, daily, sprint review synchronously. 24-48h email tag only happens with Stockholm/Helsinki clients and only at the day's edges.

Factor 4 — Geopolitical stability: Brazil became low-risk

Russia-Ukraine conflict since 2022 reorganized regional risk. Enterprise vendor audits in 2026 avoid Eastern Europe by geographic and regulatory proximity. Brazil is a low-risk jurisdiction with an IP treaty and contractual stability.

Factor 5 — LGPD aligned with GDPR

Poland/Romania operate GDPR as EU — no friction. Brazil operates LGPD, mirroring GDPR by 85% (including concepts like right of erasure, legal basis, DPO). For EU clients, a Brazil contract has practical reciprocity that makes international compliance simple.

🌍 Where Eastern Europe still wins (and it's honest to acknowledge)

For clients in Stockholm, Helsinki, Tallinn, Riga: Eastern European timezone (CET) has near-full overlap; Brazil has only 3-4h. For those cases, direct comparison is fair — and sometimes the East wins.

For very large volume (50+ devs allocated to a single client): Poland has scale Brazil is still building. For 3-15 person squads, scale isn't a differentiator.

For specific stacks concentrated in European hubs (.NET enterprise, banking legacy Java): the East has depth. Brazil has depth in Ruby, Python, Node, Go, React Native, native mobile.

A Brazilian squad with European clients works on 5h synchronous overlap — not 48h email tag

🚀 Who is making this switch in 2026

German and French fintech startups needing senior Ruby/Node pool.
Dutch and Portuguese B2B SaaS valuing product culture (not just technical engineering).
European healthtechs needing LGPD/GDPR alignment and lean operation.
British edtechs (post-Brexit) wanting to reduce hourly cost without going to India.

📢 Evaluating switching EU vendor to Brazil in 2026? Revin operates senior Brazilian squads with clients in Lisbon, Madrid, Berlin, and Amsterdam. Book a Discovery Call.

🎯 Conclusion: the equation changed in 2025, closed in 2026

For European startups in 2020, choosing Poland was obvious. In 2023, still reasonable. In 2026, it demands re-running the math — and in 60% of typical scenarios, Brazil wins. Not by marketing; by numbers.

📢 See our international case studies for examples where Revin already delivered to EU clients.

Read more at revin.com.br.

The estimate that wins the deal is the one that slips the most

Revin — Mon, 03 Aug 2026 15:55:16 +0000

Originally published on the Revin blog.

Every software proposal that promises an exact date is selling you something. Not always lying, but selling. The exact date is the line in the document written to get your signature, not to be met.

I say that as someone who writes those proposals. I have lost deals for quoting a bigger number than the competition, and early on I signed off on timelines I knew were optimistic just to stay in the running. I learned to read estimates with suspicion because I have stood on both sides of the table.

If you are the founder lining up three quotes in a spreadsheet, leaning toward the cheapest and fastest, this is about what that number hides.

Why the lowest number almost always wins

The dynamic is simple and a little rigged. You ask three vendors for a quote. One says six months, another four, the third three. With no technical way to judge who is right, you are left with the two criteria that are easiest to compare: price and time. The lowest wins.

But the lowest number is rarely the most honest. It is the most optimistic, or the one most desperate to close. A short estimate is not a sign of a sharper team; usually it just assumes everything goes right: no bugs, no rework, none of the requirements nobody mentioned during the sales call. Software never goes entirely right.

Last year we lost a scheduling system for a chain of clinics over exactly this. We quoted five months; a competitor promised two and a half at half the price. The founder took the two and a half, of course. I ran into him at a conference about seven months later. The system had just gone live, with half the screens we had scoped, and the vendor was already asking for a change order. He paid more than our five months would have cost, and shipped later. I do not tell this to sound clairvoyant. The sample is biased; I only hear about the ones that went wrong and came back to talk. But I see the pattern often enough that it stopped surprising me.

A few of the projects we picked up after an optimistic timeline blew up are at revin.com.br/en/cases, now with product in production instead of a change order on the table.

The date you circled on the calendar when you signed is rarely the date the product actually ships.

The ninety-ninety rule

There is an old engineering joke, usually credited to Tom Cargill at Bell Labs, that captures it better than any chart: the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90% of the time. Add it up, you get 180%. It is a joke, but everyone who has ever shipped software laughs a little sideways, because that is exactly how the math lands.

The reason is that the visible part of the work, the part you can demo on a nice screen, is the part that moves fast. What drags is everything else, the stuff nobody puts in the quote because it does not show up in a demo:

The error paths: what happens when the payment fails, when the connection drops mid-request, when the user does the thing you swore nobody would do.
The migration of the old data, which is always dirtier than the client admitted during the sale.
The hardening for production: performance under load, permissions, logging, the behavior at peak that the developer’s laptop never saw.

Across a rough count of the projects we have inherited half-finished, that final 10% ate something close to 40% of the total effort. I hold that number loosely: small sample, and all of them arrived sick, so it is probably inflated. Either way the direction never changes. The end costs far more than the middle seems to promise.

On paper the plan looks whole. The little boxes nobody drew are exactly the ones that hold up the delivery.

An estimate is not a fixed date

The fix is not to estimate so well you nail the date. Nobody nails the date. The fix is to stop treating an estimate as a promise and start treating it as a range. When a client asks me when it will be done, the honest answer has three numbers, not one: the good case, the likely case, the bad one. If the gap between good and bad is huge, that gap is measuring the size of what we still do not know about the problem, and hiding it behind a single number is the dishonest move.

What we do to shrink that gap is slice the work into pieces that run. Instead of disappearing for three months and coming back with "the product", we ship something demonstrable every week: small, sometimes ugly, but standing and testable by real people. The number you can trust is always the one attached to something you have already watched work. The rest is a guess wearing the costume of a commitment.

When we come into a project through a Diagnostic Sprint, a good chunk of the first conversations is recalibrating an estimate someone sold short: separating surface mess from an actual hole in the schedule.

When a tight deadline is honest

Let me be fair, or this turns into an excuse for every slip. Not every tight deadline is a lie. Some dates the world imposes on you: the regulation that takes effect, the round that closes, the industry conference that will not move to next month because your backend is late. There, a short timeline is a real constraint that came from outside, and a good team works inside it by cutting scope out in the open, without quietly cutting tests.

The difference between the two is what disappears when things get tight. An honest deadline trims the feature list and tells you. A sold deadline trims the quality and stays quiet. You only find out which one you bought once it is in production.

The honest quote costs more on paper

In the end, the founder’s choice is not between expensive and cheap. It is between paying the difference at signing or paying it later, with the interest of change orders, rework, and a product that arrives late and half-built. The honest quote almost always looks like the worse deal in the moment you decide. It is usually the only one that still respects your cash twelve months on.

If you have three quotes on the table and the cheapest one looks too good to be true, half an hour with someone who has watched this movie from both sides is worth it before you sign.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

Threat modeling in 1 hour: the method senior squads use for teams without a security engineer

Revin — Sat, 01 Aug 2026 17:48:20 +0000

Originally published on the revin.com.br blog.

Most startups believe threat modeling is enterprise stuff with a dedicated security team. Result: nobody does it, nobody reviews architecture under a security lens, and the first incident exposes obvious vectors that could have been seen in a 1-hour whiteboard session.

A senior squad runs lightweight threat modeling in 1 hour with 4 questions. It doesn't cover 100% of vectors like a formal audit would — it covers 80% at less than 1% of the cost. Revin runs this threat modeling by default in the Diagnostic Sprint for every new client.

For CTOs, tech leads, and founders whose product handles sensitive or financial data but who never had time (or budget) to hire formal security consultancy.

4 questions on a whiteboard replace weeks of formal security consultancy

🧠 The 4 questions of 1-hour threat modeling

1. "Who wins by attacking us, and what do they win?"

Defines attacker motivation. Competitor stealing customer list? Criminal asking ransom? Disgruntled employee leaking? Each motivation points to different vectors. Without defining motivation, threat modeling becomes a generic list.

2. "Where would they get in (top 3 doors)?"

Identify the 3 most likely vectors: admin login, public API, third-party integrations, employee email, code repo, compromised SaaS vendor. Top 3, not top 30 — sustainable maintenance.

3. "If they get in, what do they get and how fast?"

Blast radius mapping. Got into admin panel: access to how many customers? Got the AWS key: how much cost before detection? This exercise forces prioritization — what to defend first.

4. "What is the cheapest control that reduces 80% of the risk?"

Pareto frame. For each vector, the cheapest countermeasure: strong MFA, rate limiting, key segregation, log auditing. Senior squads know the low-cost / high-impact control map.

Output is a diagram with 5-10 prioritized threats and an assigned owner per threat

🛠️ How to run it in practice (90-min calendar slot)

15 min: tech lead sketches architecture on whiteboard — data flow, integrations, entry points.
30 min: answer the 4 questions in order, with 1 senior dev and 1 ops present.
15 min: prioritization — top 5-10 threats in impact × probability matrix.
15 min: immediate actions (P0 = this week, P1 = next month, P2 = quarter).
15 min: assign owner per threat. No named owner, no action.

Output: diagram + 5-10 line spreadsheet with action, owner, deadline. Next review in 3 months. It's not PowerPoint, it's work.

🚧 The 4 most common mistakes

Trying to cover everything: team spends 8 hours mapping 50 threats, nobody acts on any.
No motivation defined: list becomes generic ("SQL injection", "XSS") instead of product-specific.
No assigned owner: document looks great, nobody implements.
No periodic review: architecture evolves in 3 months, frozen threat model becomes fiction.

📢 Want to run threat modeling on your product in 1 real hour? Book a Diagnostic Sprint — it's included in the standard scope.

🎯 Conclusion: 1 hour today is worth more than 8 hours after the incident

Perfect is the enemy of good in SMB security. Formal enterprise threat modeling doesn't fit; senior squads ship a pragmatic version that covers 80% of risk in 1 hour. Revin runs this format with every client.

📢 See Revin's Security Foundations model — threat modeling is the first deliverable.

Read more at revin.com.br.

Hard conversation: how the CTO communicates the product needs a rewrite

Revin — Fri, 31 Jul 2026 16:38:56 +0000

Originally published on the revin.com.br blog.

Every CTO eventually has to present the hardest word to the board: rewrite. Legacy system doesn't scale, doesn't document, doesn't attract talent, doesn't meet compliance. Engineering has known for months; the CFO hears it today for the first time. The predictable reaction: 'you want to redo everything?'.

The problem is rarely the technical decision — it's the communication. A senior squad presents rewrite as a risk and timing decision, not as engineering complaint. Revin has a template that shifted the conversation across 3 clients in the last 2 years: rewrite approved in the first meeting, executed without stopping operations.

For CTOs needing to sell rewrite to CEO/CFO/board, and for founders who heard the word and are deciding whether to approve or fire the CTO.

Presenting rewrite as a risk decision (not a dev complaint) changes the board's answer

🚫 Why the traditional presentation fails

The CTO walks into the meeting with technical slides: 'code is spaghetti, no tests, old framework, team can't evolve'. CFO hears 'you want to spend money to redo the same thing'. CEO hears 'engineering isn't keeping up'. Result is defense, not decision.

The problem: the CTO presents symptom (bad code) without translating to consequence (risk in money and time). Without that translation, executives can't decide rationally.

📋 The 4-slide template that works

Slide 1 — The cost of NOT rewriting in the next 12 months

In USD: feature capacity lost (devs spend X% on workarounds), expected incident cost (probability × impact), turnover cost from technical frustration, cost of failing compliance the client is asking for. Total over 12 months.

That slide shifts the conversation. Without it, executives only see rewrite cost; with it, they see the cost of both paths.

Slide 2 — Defined scope (not "let's redo everything")

Partial rewrite is the rule; total rewrite the exception. List modules to be rewritten (usually 30-50% of system), modules to be kept (50-70%), and why each division. 'We'll rewrite payments and auth because X; reporting stays because Y'.

Slide 3 — The no-stop strategy (strangler pattern)

Executives fear 'stopping operations for 6 months to redo'. The right answer: strangler pattern. New version runs alongside old, traffic migrates module by module via feature flag, rollback possible any time. Operations don't stop; clients don't notice.

This slide eliminates the biggest executive fear. Without it, the board's 'no' is almost guaranteed.

Slide 4 — Delivery cadence and when the board measures success

Monthly milestone with business metric (not technical). Month 1: auth module migrated, login latency -40%. Month 2: payments migrated, transaction failure -60%. Months 3-6: continuation. Without business milestones, rewrite becomes an opaque project; with them, it becomes a measurable investment.

A managed squad executes rewrite with strangler pattern — operations do not stop, value keeps flowing

🛠️ How a managed squad executes rewrite without stopping operations

Strangler pattern by default — new version coexists with old, gradual migration with feature flag.
Team split between 'legacy maintenance' and 'new build'. Senior squads have capacity for both.
Parallel metrics: legacy and new system reported together for 6-12 months until full decommission.
Rollback documented per module — not 'all or nothing', but 'module X reverts to legacy if it fails'.

💸 The scenario where rewrite is NOT the answer

A senior squad also knows how to say "no" to rewrite. Cases:

Team lacks maturity to conduct rewrite — becomes infinite refactor with no progress.
Product is in product-market-fit validation — focus on iteration, not re-architecture.
Legacy maintenance cost is < 30% of rewrite cost. The math doesn't work.

Revin operates with a 'refactor before rewrite, rewrite when refactor doesn't fit' bias. Clients will save money more often than they'll approve a rewrite — and that honesty is the differentiator.

📢 Have a legacy system demanding a decision and the CTO has no framework to present? Book a Diagnostic Sprint — Revin delivers analysis in 2 weeks with ready slides for the board.

🎯 Conclusion: rewrite is an executive decision translated by engineering

A CTO who presents rewrite as a technical problem gets 'no'. A CTO who presents it as a risk decision with scope, no-stop strategy, and business metric gets 'yes'. Senior squads conduct that translation; generic squads keep complaining in retro.

📢 See our cases to see where Revin led a rewrite with a client without stopping operations.

Read more at revin.com.br.

Who Found the Outage First — You or Your Customer?

Revin — Fri, 31 Jul 2026 16:21:16 +0000

Originally published on the Revin blog.

Saturday morning, a little before ten, a founder I had never spoken to reached out, referred by one of our clients and looking for a second opinion. He forwarded me a screenshot. It was not his own: it came from one of his customers, posted in a buyers’ group, showing the checkout error screen with the caption "this again?". He had asked the agency running his system how long payments had been down. Nobody could tell him. The vendor’s monitoring dashboard was all green.

What bothers me about this is not that the system went down. Systems go down; that is the nature of the thing. What bothers me is the order in which people found out: the buyer before the founder, the founder before the vendor he pays precisely to watch it.

If you outsource your engineering and you keep learning about production outages from the people who use your product, this is about the question almost no one asks before signing: when it breaks, and it will, who finds out first?

The dashboard was green. The system was not.

The vendor’s dashboard showed everything in place because it was measuring the wrong thing. CPU at 30%, memory calm, the server answering the health check every thirty seconds. None of that is a lie. It is just that none of those metrics knows whether a customer can actually complete a purchase.

The classic health check hits a route like /health and gets back an "ok". That route tends to answer "ok" even when the payment service is down, because it never touches the payment service. The server is up, passing a test it was written to pass.

Green, there, only means the process did not die. It is the lowest ceiling of health there is, and even so it is what a lot of contracts treat as good enough. When we take over a product in a Diagnostic Sprint, one of the first things I open is the list of configured alerts. I have seen a product run for two years with exactly one alert wired up: "server not responding". Nothing about errors, latency, or a stuck queue.

A dashboard full of colorful charts can be all green and still say nothing about whether a customer managed to check out.

What the customer feels does not fit on a CPU graph

The shift is easy to say and tedious to do: measure symptoms, not resources. Your user does not feel your CPU usage. They feel the button spin for eight seconds and come back with an error. Monitoring that earns its keep watches the experience of the person on the other side of the screen and turns that into signals that wake someone up.

In practice it comes down to a handful of alerts any team can set up in an afternoon:

Error rate: the share of 5xx responses above a threshold (say, 2% over a five-minute window) fires an alert instead of waiting for a support ticket.
Latency that matters: not the average, which hides everything, but p95. If the 95th percentile on checkout crosses one second, someone should know before it turns into cart abandonment.
Synthetic check: a bot that every minute replays the real customer path (log in, add to cart, pay in a test environment) and screams when any step stalls.
Queue and job: if order processing stops moving, the server stays green, the customer waits on a confirmation that never arrives, and no health check notices.

None of these alerts is expensive or exotic. Datadog, Grafana, or even a cron job with curl and a Slack webhook cover the basics. When it is missing, it is almost never about budget. It is that nobody stopped to think about the customer before the incident happened.

We wire up this mesh of signals in the first weeks of any project; if you want to find out what your current monitoring simply ignores, you can map that in a diagnostic before the next Saturday does the job for you.

A server that is up, answering the health check every thirty seconds, has no idea the order queue stopped moving inside it.

Not every system needs a 3 a.m. on-call rotation

I have to be fair here, or this turns into scaremongering. Not every piece of software deserves round-the-clock on-call. If your product is a landing page, a five-page brochure site, or an internal tool four people use during business hours, standing up a PagerDuty rotation is swatting a fly with a sledgehammer. A plain email alert does the job and you move on.

The question that separates the two cases is blunt: if this goes down for an hour on a Sunday, does someone lose money, trust, or data? When the answer is no, relax, genuinely. When it is yes, and for almost any product that makes money it is yes, learning about the outage from your customer is not an operational footnote. It is business risk nobody priced in.

The team that stays turns on the alarm the cheap one never did

Here is the difference that never shows up in the proposal. The cheap vendor ships the requested feature and disappears. Wiring up an alert is not a screen the client drew into the scope, so it does not fit the tight budget that won the bid. The incident, when it lands, is already your problem.

At a logistics client we took on last year — lean team, six people — the first week had no new code at all. It was instrumentation: per-route error alerts, p95 on the delivery-scheduling screen, a synthetic check replaying the tracking flow every minute. The following Tuesday the synthetic fired at 6:47 a.m.; an overnight deploy had broken the tracking route. The team fixed it before the first customer opened the app.

Before that, their average time to notice an outage hovered around two hours, always through a complaint. That number came from their own account, not a dashboard, so I hold it loosely: it may be inflated by the memory of people who were furious. Even cutting it in half, an hour with the scheduling screen down during a late-afternoon peak is not cheap.

That is what a team that stays does by habit: it ships the feature already carrying the eyes that will watch it afterward. Monitoring ships in the same package as the feature, and it is part of calling the delivery done.

A few of those cases, with live product names instead of screenshots, live at revin.com.br/en/cases.

The cost of the silence

The founder from Saturday’s screenshot is still rebuilding trust with that group of buyers. The bigger loss was not the hour of checkout being down. It was the customer realizing no one on the inside was watching. That shows up on no graph, and it is the slowest thing to earn back.

Everyone asks a vendor whether they ship fast. Almost no one asks how they will know when it breaks. And it is that second answer that decides whether, next Saturday morning, the one who tells you is your monitoring or your customer.

If you have already lived one of those Saturdays and would rather skip the next, book a call with us and we will look together at what your system is not telling you today.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

Why I almost never approve a full rewrite of your product

Revin — Wed, 29 Jul 2026 14:31:18 +0000

Originally published on the Revin blog.

On a Tuesday in April, the founder of a logistics startup called me with his mind already made up. Three years of product, a team of five, and the line I hear about twice a month: "the codebase is rotten, let's rewrite the whole thing from scratch and do it right this time." He wanted Revin to run the rewrite. I spent the next forty minutes of that call trying to talk him out of it.

Not because the codebase was good. It was genuinely bad; I had taken a look before the call. The point is different: a rewrite from scratch is almost always the most expensive decision a founder signs off on all year, dressed up as courage. I have watched that movie enough times to be scared of it.

If you have a vendor, a developer, or your own tired brain suggesting you wipe it all and start over, this piece is about the bill nobody puts on the rewrite slide.

The urge to start over is not stupid

Let me be fair to the people who want to rewrite. Reading code someone else wrote in a hurry is one of the most thankless jobs in engineering. You open a thousand-line file, there are no tests, the variable names lie, and every time you pull one thread three others move. Against that, the blank page feels like rest. Starting over is the fantasy of every developer who inherited a mess, and I understand the fantasy because I have had it too.

The problem is who profits from it. When a vendor pitches you a full rewrite, they are selling you six, eight, twelve months of fresh work where they barely have to understand what already exists. It is comfortable for them and costly for you: they swap the hard part, reading and fixing what stands, for a fun part that you finance. That is why, when the logistics founder came to me, my first job was to block the easiest sale I could have closed.

The blank page of a new project feels like relief. It is also where the bill starts climbing.

The bill that disappears from the slide

The rewrite reaches the founder as a single number: what it costs to build the new thing. What drops off the slide is the rest of the bill, which is usually bigger. While the new team writes, the old system stays up, serving customers, breaking, charging for maintenance. You pay for two products at once, one dying slowly and one not yet born.

There is also the tax nobody warns you about: you will reintroduce bugs you had already fixed. That weird if-statement in the middle of checkout that nobody understands is usually there because a real customer broke in a specific way back in 2023. The rewrite erases that scar without knowing it existed, and you reopen the wound months later, rediscovering the hard way why the old code was ugly.

A client of mine from 2023, an auto-parts marketplace with around forty thousand SKUs, spent seven months and roughly $68,000 on a rewrite that never replaced the old system. The two ran side by side until cash got tight. When they stopped, they had migrated about 40% of the screens and burned out a whole team. They went back to the old system, now with half the people to maintain it.

Of every ten founders who come to me wanting to rewrite, about eight did not need to. I know that number is biased: the ones who rewrote and won do not call me to brag, so my sample is made of people it went badly for. But even cutting it in half, that is still too many spending for nothing on a decision that felt obvious on a bad night.

Three questions before you rewrite the first line

Before I approve anything, I make the founder answer three questions out loud. They are not clever. They just separate the rewrite that is a need from the rewrite that is fatigue.

Is it architecture or is it mess? Mess gets refactored without throwing anything away. Genuinely wrong architecture (a database that cannot hold the business model, a stack choice that jams the product) is rare, and it is the one case where a big rewrite tends to pay for itself.
Can you freeze features for six months? An honest rewrite means you stop evolving the product while it is rebuilt. If the business cannot survive that freeze, the rewrite starts out losing to the competitor who kept shipping.
Does anyone still understand the current system? If the knowledge left with the old vendor, you will not rewrite the product: you will rewrite the same mistakes in the dark, without even knowing what they were.

If the answer to any of the three makes you uncomfortable, the rewrite will probably hurt more than the codebase you want to throw out.

A historic building restored with scaffolding outside while life goes on inside. That is how an old codebase improves without closing its doors.

The dull path that usually wins

There is an alternative nobody puts on a slide because it is unglamorous: improve what stands, one piece at a time, with the product live the whole way through. The jargon for it is the strangler fig. You grow the new around the old and choke it out module by module until the old one disappears on its own. No big cutover day, no pretty photo. Just a release every week.

That is what we ended up doing with the logistics startup. No starting from zero. The first two weeks were pure reading: mapping what existed, writing tests over the current behavior to lock down what already worked, and finding the rottenest module. It was the routing engine. We rewrote it behind a stable interface, the rest of the system never noticed the swap, and we moved to the next one. About six months later, most of the critical code was new and the product never went down for a single day. That is the kind of decision we pull apart right in the diagnostic.

Rewriting behind an interface is not slower than a big bang. It is usually faster, because every week ships something you can test with real users, instead of betting six months on a single flip that might not even go live. The dull part is exactly the part that protects your cash.

Back to that Tuesday call

The logistics founder did not rewrite. We strangled the worst part first, he kept selling the product during the work, and the dream rewrite he had quoted with another vendor, nearly a year of standstill, never had to exist. He told me afterward that the most profitable decision of that year was the one to do nothing heroic.

If someone is pushing a from-scratch restart on you right now, be suspicious of whoever gains from the delete button. Before you sign, half an hour looking at your codebase with people who read code for a living is worth it, and that is usually where the conversation starts.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

The team they sold you isn't the team that ships your code

Revin — Mon, 27 Jul 2026 18:42:13 +0000

Originally published on the Revin blog.

Last week a founder sent me two files in the same email, barely a line of text between them. The first was the deck an agency had used to win his contract the year before: seven senior names, three with conference-stage photos, one case study for an app everyone in the room would recognize. The second was the git blame of his product, ten months after signing. Eighty-two percent of the commits came from two logins he had never once seen in a meeting.

He asked me if that was normal. I told him I see it often enough to be bothered by it, and that almost nobody checks before signing. Least of all when the vendor sits in a country you will probably never visit, in a time zone where most of the agreements happen in writing.

If you hire engineering outside your own country on the strength of a proposal, a portfolio, and one friendly sales call, this piece is about the question that usually goes missing: who, exactly, writes your code once the pen touches the paper?

The hand that signs the contract is almost never the hand that writes the code.

The pitch cast is on loan

A proposal is a sales event, and every sales event has one goal: close. To close, you put the most impressive people you have in the room. That, by itself, is not dishonest. It is how nearly every service sale works, from consulting to construction.

The trouble starts afterward. The person who shone on the call is a scarce resource, and a scarce resource gets spread across many deals. Once you sign, they rotate to the next pitch, and your account falls to whoever is free on the calendar. It is a trailer cast: what you meet at the premiere is gone by the time the film starts.

In a managed squad, like the ones we build at Revin, the lineup goes in the contract, with each person's name and seniority. That is not red tape. It is how you keep the deal from depending on whoever happened to have an open calendar the week of the sale.

What the deck never shows

Every portfolio is an edit. The agency picks the cases that photograph well and leaves out the rest, which is fair. It stops being fair when the edit hides three things that would change your decision.

A case with no scope: "we worked with brand X" can mean one developer parked on it for six weeks, on a product that already existed.
A portfolio with no live link: a screenshot is not shipped software. Ask for the URL and the name of whoever built it.
A team of experts with no names: an adjective is not a lineup, and seniority that will not fit in the contract usually will not show up in the work.
Quiet subcontracting: part of what you pay can be handed to a third party who never joined a single call with you, and your code passes through hands that are not on any contract.

From a distance, the border helps hide all of it. You do not call the previous client, because they are nine hours away, busy, or because the contact from the slide simply does not pick up.

The person writing your code in month three is rarely the one who showed up on the sales call.

The bill arrives as ghost seniority

The damage from this setup never shows on the invoice. You pay a senior rate and get junior work without review, because the senior who would review it is out selling somewhere else. The code moves, but it moves crooked: a giant PR approved in two minutes, the same function copied across three screens, tests nobody wrote.

In the logistics case that opened this piece, we put the rework from the first ten months at somewhere around $38,000. I rounded that down on purpose, because part of it was refactoring they would have done anyway. Even cutting a third, it is far too much for a problem that started in a sales meeting.

When we take over a product like that in a Diagnostic Sprint, the first read already gives away who wrote it before us: you can see in the history where there was real senior work and where someone was learning on your codebase.

Distance becomes a problem when it hides the team

I have to be honest here, because the easy argument would be 'distrust foreign vendors,' and that argument is lazy. I work for a vendor that is 'foreign' to most of our clients, who sit in the US and the UK. Distance, on its own, says nothing about quality.

Opacity is what costs you. Distance only hurts when it hides who does what. A vendor three time zones away who gives you repo access on day one, shows you who commits, and answers for every delivery is closer, in practice, than the agency down the street that vanishes after lunch. What you need is to see the work, wherever it happens.

🔎 How to check that the pitch team is the code team

You can guard against most of this before you sign, and none of the checks is expensive. The first is to ask for each person's name and seniority inside the contract, not on the slide. A serious vendor writes it down; the one that dodges answers with "our team of experts."

The second is to arrange repo access from day one and actually look at who shows up in the history during the first weeks. If the commit names do not match the pitch names, you already have the conversation you need to have early, while it is still cheap to fix.

The third is the reference check almost nobody runs: talk to a current client of the vendor, not the logo on the slide. Twenty minutes with someone in the middle of a contract tells you more than any case study.

And the most honest check of all is working together before you commit. That is why we sell two weeks of Diagnostic Sprint before any long contract: the people who run the diagnostic are the same ones who stay if you go ahead with us. There is no separate sales team and delivery team.

The question that belongs before the pen

The logistics founder is still with us, rebuilding what could be rebuilt. He said something that stuck with me: he had compared six proposals line by line, put price, timeline, and stack in a spreadsheet, and never once asked who would be typing.

Everyone compares the price on the proposal. Almost nobody asks who sits down to write the code every day, and that second answer is the one that decides how your year goes.

And no, not every project needs this care. If your 'system' is a five-page brochure site, hire a good freelancer and get on with your life; A-team and B-team come out the same when the work is small and finishes fast.

If you want to see who actually shows up on our projects, the cases are at revin.com.br/en/cases, with live product names instead of screenshots. And if you already have a proposal in hand and want to check whether the slide team is the commit team, book a call with us before you sign.

We write about software engineering, managed squads and technical decisions every week at revin.com.br.

Squad as a service: what it is and when it makes sense

Revin — Mon, 27 Jul 2026 18:42:03 +0000

Originally published on the revin.com.br blog.

Squad as a service is the model where a company hires a complete engineering team, with defined seniority, technical leadership, and delivery rituals, for a flat monthly fee. The team works on your product as an extension of your own people, but management, quality, and replacing anyone who leaves are the vendor’s responsibility.

The term has been gaining ground alongside a growing distrust of two older models: staff augmentation and fixed-scope project shops. I do not have search volume data to prove that curve, I will admit. What I have is Revin’s inbox, where "do you offer squad as a service?" has become a weekly question, from Brazilian founders and US ones alike.

This guide is the piece I wish I could send everyone who arrives with that question: what the model actually is, what usually gets disguised under the name, what it costs, and how to decide whether it fits your stage.

The difference between a squad and staff augmentation usually shows up in the first sprint

What it is, minus the marketing

The word doing the heavy lifting is managed. In squad as a service, the vendor answers for delivery: they assemble the team, put a tech lead in front of it, run the rituals (standups, sprint planning, a weekly report), and replace people when someone leaves, at no extra cost and without you becoming a recruiter. You track outcomes; whoever sells the service operates the team.

What the model is not: five résumés dropped into your operation with a nice name on the proposal cover. If you are the one managing the people, chasing delivery, and onboarding a replacement when someone quits, you did not buy a squad as a service. You bought staff augmentation at squad prices.

How it works in practice

The typical composition pairs a tech lead with senior and mid-level engineers, sized to the backlog. At Revin, the smallest format has three engineers and the most common has five with a dedicated tech lead. The team joins your Slack, shows up at standups, ships straight to your repository, and closes every week with a report you can read in five minutes.

The first two weeks are about context: the product, the codebase, how decisions get made in your company. That investment is what separates a team that accumulates knowledge of your product from a vendor that starts from scratch on every engagement. At one Revin client, a five-person squad picked up a backlog that had been stalled for almost three months; by the third sprint, delivery pace had doubled what the internal team managed alone, with nobody on the client side turning into a project manager along the way.

The full picture of the model, including the composition of each plan and what happens in the first two weeks, is at revin.com.br/en/how-it-works/squads.

How it differs from staff augmentation and project shops

With staff augmentation, you buy hours of people and get the management thrown in for free. Except the freebie is your own workload: definition of done, chasing delivery, integrating the augmented staff with your team, all of it stays on your side of the table. It works when you have technical leadership to spare. Few teams do.

With a fixed-scope shop, the contract locks a scope upfront. The vendor’s incentive becomes shipping what the paper says, even when the product has already asked for something else halfway through, and every adjustment turns into a change request with a new price tag. For genuinely stable scopes the model can hold up; a living product rarely is one.

With squad as a service, the contract is monthly, the team composition is known, and responsibility for delivery has a first and last name. It is the only model Revin operates: no staff augmentation hiding behind the proposal, no change request queue, and thirty days’ notice to leave.

Objective criteria shorten vendor selection more than another round of proposals

What it costs in 2026

Nearshore guides quote anywhere from $8,000 to $30,000 a month for squads of four to six people in Latin America. Revin publishes its own table: from $12,000 for three engineers and $22,000 for five with a dedicated tech lead, composition open on the site.

Victhor opened up the whole calculation, market ranges and the three questions that deflate a padded proposal included, in how much does a development squad cost in 2026. The official table, plan by plan, is at revin.com.br/en/pricing.

When it makes sense (and when it does not)

The model shines in three situations: a continuous roadmap with six or more months of work ahead; a small internal team that became the bottleneck and has no time to hire; and the post-agency rescue, when the product arrived broken from a previous vendor and needs senior hands to stabilize before it can grow.

And it is not for everything. A five-page marketing site, a campaign landing page, a prototype to validate an idea with no users yet: a good freelancer solves those for a fraction of the price, and recommending a squad would be overkill. Squad as a service is for a living product with a backlog that does not end.

How to pick a vendor without getting played

After reading dozens of proposals in this market, the criteria that actually separate a serious vendor from old models in new packaging fit in a short list:

Public pricing: a hidden table usually means a proposal tailored to your budget.
Names and seniority in the contract: "a team of experts" is not a composition.
Thirty days’ notice to leave: a six-month lock-in signals a vendor that does not trust its own delivery.
Rituals written into the proposal: standups, sprints, and a weekly report with an owner and a cadence.
Replacements on the vendor: if someone leaves the team, that problem cannot become yours.

If you are torn between two finalists, two weeks of a Diagnostic Sprint with one of them will tell you more than another round of proposals: a paid, fixed-scope audit that maps code, delivery, and team before you sign anything long. The format is at revin.com.br/en/diagnostic-sprint.

The model is here to stay; the name, maybe not

Three years from now, nobody may say "squad as a service" anymore, the same way "software factory" now sounds like another era. What should remain is the structure: a complete team, managed by the vendor, with an honest contract for getting in and getting out. That is what deserves your attention when the next buzzword arrives.

If you want to see the model running on real products, Revin’s case studies are at revin.com.br/en/cases. And a 30-minute conversation usually settles more doubts than ten articles: revin.com.br/en/discovery-call.

Read more at revin.com.br.

How much does a development squad cost in 2026?

Revin — Mon, 27 Jul 2026 18:41:51 +0000

Originally published on the revin.com.br blog.

A squad of three engineers starts at $12,000 a month at Revin. Five engineers with a dedicated tech lead, $22,000. That is not a teaser rate or a lead magnet: it is the table published on our pricing page, team composition sitting right next to it.

I am writing this because the same scene keeps playing out. A founder googles what a development squad costs, reads half a dozen articles that spend eight hundred words saying "it depends", and lands on a contact form. The real number shows up later, in a sales call, tailored. Tailored to the size of your budget, that is.

This article is the open math before the sales call: what goes into a managed squad price, the ranges vendors actually charge, and the questions that separate a serious proposal from a padded one.

When pricing is public, the sales conversation starts in the right place

Why almost nobody publishes pricing

The short answer: hiding the number is profitable. A closed proposal lets a vendor price the client, not the work. Last year a logistics founder showed me the three proposals he had received for the same scope, same brief, same discovery call. The cheapest came in at $9,400 a month. The most expensive, $27,500. None of the three said who would actually do the work or how senior they were.

When a vendor publishes pricing, that game is over. Revin publishes because we run managed squads as a product, not as bespoke projects: floors on the site, real ranges, a custom quote only when the work genuinely falls outside the standard. Do we give up anchoring margin? Sure. We also get conversations that start in the right place.

What the monthly fee actually covers

A managed squad is not a sum of salaries. The monthly fee covers the team (a senior and two mid-levels on Starter; a tech lead, two seniors and two mid-levels on Standard), but mostly it covers what makes that team run without you becoming its project manager:

Technical leadership: architecture, stack decisions, and code review that is not a rubber stamp.
Delivery rituals: standups, sprint planning, and a weekly report you can read in five minutes.
QA and documentation built into the flow, not sold as a separate "phase".
Replacing people at no extra cost: if someone leaves the squad, that is our problem.

In a classic bodyshop, every item on that list becomes a new line on the invoice. Or, worse, it quietly does not exist, and you find out in month three when you ask who has been reviewing the code.

The cost that never shows up in the proposal is usually what settles the bill

What the market charges in 2026

The nearshore guides that rank on Google quote anywhere from $8,000 to $30,000 a month for squads of four to six people, with senior rates in Latin America running $35 to $99 an hour depending on who you ask. Read those numbers with some skepticism: nearly all of them come from vendors who will not show their own price. Mine is a vendor number too, I will admit. The difference is that it is published, composition included, and you do not need a call to check it.

What moves the price inside that range is less mysterious than it looks: average seniority, dedicated versus shared tech lead, contract minimums, and how much management is baked in. A $10,000 squad advertised as five seniors probably has two mid-levels and someone whose badge is still warm. The full Revin table, plan by plan, is at revin.com.br/en/pricing.

For calibration against hiring: three senior engineers in the US run about $45,000 a month fully loaded, before you count the three to five months of recruiting. That gap is why a Brazil-based squad works even for companies that already have in-house engineering: overlapping working hours with the US, and capacity that arrives already functioning.

Three questions that deflate a padded proposal

If you have proposals on the table right now, three questions settle most of the evaluation. They are the same ones I ask when Revin loses a deal and I want to understand who we lost to.

1. Who, by name and seniority, will work on my product?

A serious proposal answers with people. A padded one answers with "our team of experts". If the vendor cannot say who, the price has no backing.

2. How much of the fee is engineering and how much is management?

There is no correct ratio, only a transparent one. Management baked into the fee is healthy when it shows up in the composition. When it shows up nowhere, it is usually hiding inside the hourly rate of the people writing code.

3. What happens if I want out?

Thirty days notice is the standard of a vendor that trusts its own delivery. A six-month termination fee is the standard of one that knows you will want to leave. And if the real doubt is the state of your codebase before you sign anything, a two-week Diagnostic Sprint maps code, delivery, and team for a fixed fee: revin.com.br/en/diagnostic-sprint.

The price that never shows up in a proposal

In 2024 I watched a fintech switch to the cheapest vendor in the running and save $5,200 a month for four months. In month five, they paid $7,800 in rework to redo a payments integration that had been delivered as "done". The spreadsheet savings did not survive the first production incident.

Squad pricing is compared on open composition, exit terms, and someone answering for delivery. We can run that math together in a 30-minute call, no strings attached: revin.com.br/en/discovery-call. And if you want to see what it turns into, the case studies are at revin.com.br/en/cases.

Read more at revin.com.br.