Day Mode ->

The RFP looked perfect. Twenty minutes of checks proved it was fraud.

On July 14, 2026 our contact form delivered the kind of message every development agency hopes for. A web-based medical supply chain platform. Pharmaceutical traceability from manufacturer to end consumer. An MVP for enterprise and government stakeholders, with a technical roadmap ready to share. Polished English, plausible scope, a name and a phone number.

It deserved a reply. It also deserved a background check, and that is where it fell apart.

We are publishing the whole exchange, quoted in full, because the same template is almost certainly sitting in other agencies' inboxes right now. If you are here because you searched one of these, you are in the right place:

bjarnen@enterprisolutioninc.com

enterprisolutioninc.com

8282762373 (+1 828-276-2373)

Bjarne Nikkila, a name that does not belong to the person using it. More on that below.

What arrived

The contact form, verbatim:

We are currently in the early stages of developing a web-based medical supply chain management platform aimed atimproving pharmaceutical traceability, prescription control, and regulatory compliance. The goal is to build a system that enables seamless tracking of medical supplies from manufacturers to retailers and ultimately to end consumers, ensuring transparency and accountability across the entire supply chain.

At this stage, we are looking to collaborate with an experienced development team to help implement the solution and deliver an MVP for presentation to enterprise and government stakeholders.

If this aligns with your company's expertise, I would be happy to share more details and explore a potential collaboration.

Read it twice and you can see the seams. "aimed atimproving" is missing a space. The double spaces scattered through it are the fingerprints of text pasted from somewhere else. The sentences are polished, the assembly is not, and no company is named anywhere in it. On a busy Tuesday none of that stops you. It is a good message.

The first pass (twenty minutes, no special tools)

Before replying we ran the basics.

An RDAP lookup showed the sender's domain was registered on June 5, 2026, thirty-nine days before the message, on budget hosting with a one-year term. The company website served a completely empty page. The name traced back to a real person in Finland, a hotel project manager with no visible connection to any of this. The phone number carried a North Carolina area code, which sat oddly against a Finnish name and a company that no search could find.

None of this was final proof. Young domains exist. Real people have thin footprints. Plenty of legitimate work arrives from a founder with a new domain and a borrowed phone. So we did the only thing that settles it: we asked.

The test

We replied politely and asked for three things any real company answers in one line: the legal entity and country of registration, a company website or LinkedIn page, and the sender's role. No booking link, no documents, nothing until those arrived.

The answer came back in nine minutes:

Thank you for your interest!

To give you a bit more context, the project revolves around creating a web-based platform designed to track medicines and medical supplies as they move through the supply chain. The primary focus will be on pharmaceutical traceability, ensuring that all drugs are tracked from manufacturing to final sale. [...]

Key features of the platform include:

Registration of Drug Types and Licensing: Governments can issue licenses for manufacturers to produce specific drugs. Medicine Tracking: Each medicine unit will have a unique identifier (UUID) to ensure traceability throughout the supply chain. Ownership Transfer Tracking: Medicine ownership will be transferred from manufacturers to pharmacies, and from pharmacies to consumers, with full audit trails. Public Verification Portal: Citizens can check the authenticity and history of the medicine they are purchasing by entering the UUID.

[...] We've created a project overview and technical roadmap for the next phase of the project, and we're looking to partner with a team that has expertise in developing secure, scalable web applications for this kind of platform.

If this project is of interest, I'd be happy to share the documentation so you can dive deeper into the details.

Nine minutes of enthusiastic detail, and not one word of it answers any of the three questions. Notice what it does instead. It floods the channel with plausible technical texture, then reaches for the close: let me send you the documentation. That is the whole message. Everything above it is set dressing.

The confession

So we asked again, conceding nothing:

Before we exchange documents or schedule anything, we do need the company details from my previous message: legal entity name and country of registration, a company website or LinkedIn page, and your role. This is a firm prerequisite for all enterprise engagements on our side.

Once we have those, I'll gladly review the documentation.

The reply was two lines:

Okay.

linkedin: [a link to a real US IT consulting firm, redacted here]

That looked like an answer. It was the confession.

The firm on that page is real, established, and has roughly 146,000 followers. It does VMS and MSP staffing. It has nothing to do with medical supply chains, and it certainly did not send us this message. Its actual domain is spelled slightly differently from the domain in the sender's email address. Two letters dropped from the word "enterprise". Someone registered a typosquat of a legitimate company's domain five weeks earlier and was borrowing that company's LinkedIn credibility while writing from mail servers they control.

We are not naming that firm. It is a victim here too. The fraudulent domain is enterprisolutioninc.com, and we name it so that anyone else contacted from it can find this page.

The part that should worry you: it all authenticated

Here is the detail we did not expect, and it is the reason this article exists rather than a note in our own wiki. We pulled the raw headers of that last message:

dkim=pass header.i=@enterprisolutioninc.com header.s=hostingermail-a

spf=pass (google.com: domain of bjarnen@enterprisolutioninc.com designates 23.83.209.93 as permitted sender)

dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=enterprisolutioninc.com

SPF passed. DKIM passed. DMARC passed. Every authentication check an email can face, cleared. No spoofing warning, no red banner, nothing for a spam filter to catch.

That is not a failure of the checks. It is what they are for, and people routinely misread it. Email authentication proves that whoever sent the message controls the domain in the From line. It does not say the domain is honest, or old, or who registered it, or whether it is one typo away from somebody else's company. He owned the typosquat, so it authenticated perfectly. The same headers show the mail leaving the same budget host where the domain was registered five weeks earlier, which is the only thing in that block that actually tells you something.

If your inbound process treats "passed authentication" as a trust signal, it is not a filter. It is a rubber stamp on anything a scammer can buy for the price of a domain.

About the name

The sender signed as Bjarne Nikkila. That name belongs to a real person in Finland, a project manager in the hospitality industry who has no connection to any of this, did not write to us, and almost certainly has no idea his name is being used this way. He is a victim of this, exactly as much as the consulting firm is.

We thought hard about whether to print it. The argument that decided it: a target who receives this pitch and googles the name will find the real man's profile, see a plausible professional with a real history, and feel reassured. That is precisely the effect the borrowing is designed to produce. The only way to break it is for this page to appear in that same result list.

So, plainly: if you were contacted by a Bjarne Nikkila writing from enterprisolutioninc.com, you were not contacted by Bjarne Nikkila.

What the next step would have been

We stopped there, so we describe the pattern rather than our own experience. Fake RFP scams against agencies typically escalate one of two ways. The first is project documentation, which is where this one was clearly heading: a macro-laden Word file or an archive that delivers malware to the machine of whoever opens it. He offered it twice. The second is a payment setup: an overpayment with a stolen card followed by a refund request, or a routing into fake escrow. The pitch is generous because the project does not exist.

Agencies make good targets. We are trained to treat every inbound as a potential client, we open files called requirements all day, and a government-scale project flatters exactly the ambition most agencies have.

The twenty-minute checklist

1. Run an RDAP or whois lookup on the domain. Registration date is the loudest single signal. Enterprise scope claimed from a five-week-old domain is a contradiction you can trust.

2. Load the website. Real companies have real pages. An empty page or a parked template ends the conversation.

3. Compare the email domain letter by letter against the company it claims to represent. Typosquats survive a glance and die under a careful read.

4. Reverse-check the names. Search the person together with the company, not separately. Borrowed identities look perfect on their own and fall apart in the pairing.

5. Read the headers, and know what they mean. SPF, DKIM and DMARC passing tells you the sender controls the domain. It is not a verdict on the domain. What the headers do give you for free is the sending infrastructure, and cheap hosting under an enterprise claim is a mismatch worth noticing.

6. Ask for the legal entity, the website, and the role. Then watch what happens. Real contacts answer in one line. Scammers dodge, send another template, or fake it. The dodge is the data.

If this template hit your inbox too

If a medical supply chain RFP from that domain reached you, you now know what it is. Feel free to link this page to whoever handles your inbound.

And if you are a founder evaluating development partners, notice what the checklist actually is. It is twenty minutes of refusing to accept a claim without a receipt, applied to someone we badly wanted to be real. That is not a special occasion for us. We check facts the same way before we commit to a codebase, an estimate, or a claim on this website. More on how we work: vevidi.com homepage. Inherited a live app: Rails rescue. Structural debt: Legacy modernization.

Contact Us