We build and run the middleware layer between any two systems that need to exchange data — business software, marketplaces, data warehouses, cloud, email, social channels.
That list is not a limit. What matters is whether two systems can exchange data at all — not what category they belong to.
Three problems, in the words customers actually use when they call us.
A 20-to-200-person company usually already has plenty: sales software, a CRM, accounting, inventory, marketplaces, plus email, a data warehouse, cloud infrastructure and a few comms channels. Each does its own job well. None of them owns the data flowing correctly between them. So people become the middleware: copy by hand, export to Excel, re-enter, and get it wrong.
Calling the API is the easy part. The hard part only shows up weeks into production: the same event arrives twice and creates a duplicate; a webhook drops one transaction and nobody notices until month-end reconciliation; an invoice is edited or voided but the target system still holds the old state.
Your POS vendor owns the POS. Your CRM vendor owns the CRM. The freelancer wrote a script and moved on. When the data is wrong there is nobody to call, and no log to tell you where it broke. That gap is where hecigo sits: we own the middle layer, with a name on it, a log, and someone on call.
Calling an API is 20% of the work. The other 80% is what follows — the part that only shows up weeks into production, and the part that decides whether the integration lives or dies.
Two different kinds of duplication, handled separately. Duplicate events use an idempotency key with a database-level constraint. Duplicate customers use a matching ladder that you define — which tiers merge automatically, and which go to a human.
Events are written to the log before anything is pushed, so an outage at the target never turns into data lost at the source. Scheduled reconciliation actively counts back to catch whatever the webhooks dropped.
Give it an invoice number and it returns when the source sent it, when the middleware received it, when the target accepted it, where it failed, and how many times it retried. Everything we build is handed over complete enough for another team to take over.
Community nodes live on npm. MIT licensed, fully open source.
You pay for the step you are on, see the result, then decide whether to continue. This is not about trust: nobody can quote accurately before seeing real data — not even the most experienced team. API docs always diverge from actual behaviour, and always at the expensive parts.
1–2 weeks
A written technical assessment, complete enough for anyone — including another vendor — to quote accurately.
You read the assessment, then decide whether to run a POC. The assessment is yours — take it to another vendor if you want.
1 flow · 20–50 transactions
Measurable proof, against acceptance criteria agreed before a line of code is written.
Pass every criterion and we scope production. Fail and we stop — you keep the assessment and the POC source code.
4–8 weeks per system pair
Middleware running for real, with monitoring and documentation.
An operations runbook and a handover session, before anything moves to managed ops.
monthly · ongoing
Someone is accountable when the middle layer breaks. Projects end. Operations do not.
New business flows, connecting a third system, or rewrites when a third party ships a breaking API change.
You can leave hecigo without losing anything. It sounds backwards next to managed operations, but selling the exit makes the entrance far easier — what clients fear most is being locked into a small vendor.
Triggered at any time, or bought on its own if you want to run it yourself from day one.
Step one is not free. A free assessment has three consequences: the client is not serious, we get no access to real data, and the proposal is forced to guess.
Start with discoveryMechanics, failure modes, and what we learned building this for real — including where we got it wrong. Written in Vietnamese.
Vercel vừa ra mắt công cụ kiểm tra độ sẵn sàng của website đối với AI agent mang tên Is Agentic(https://is-agentic.com), cho phép lập trình viên đánh giá k
Scrape, crawl, map, search, extract and batch scrape all return web content. Picking wrong costs you an order of magnitude in time or credits. Here is the decision, and the async behaviour that changes how you wire the workflow.
The node works on the first try in test mode. Then you activate the workflow and nothing arrives. Five failure modes we hit running Zalo Bot Platform through n8n, and why each one happens.
hecigo does exactly one thing: the layer in between. A 20-to-200-person company usually has enough software already, and each piece does its own job well. What is missing is whatever makes them talk to each other — and no vendor takes responsibility for that part.
We work in gated steps: a paid discovery, then a POC on your real data, then production. Every step has an exit. You pay a small amount, watch it run, and only then decide whether to continue.
We have shipped production integrations with Base CRM, Lark Suite and Odoo — some under contract, some while running those systems from inside the business. Plus two open-source nodes live on npm with outside users, and integration infrastructure we have operated ourselves for months.
Even so, every pair of systems fails in its own way, and most of it lives in what the API docs never mention. Nobody can quote accurately before looking at real data — not even the most experienced team. That is why discovery and a POC exist: so you don't have to take our word for it.
Not a slogan. Three real steps: discovery to understand the data, a POC to prove the approach holds, then production. Each one is a gate you are free to stop at.
Which two systems are out of sync, and where exactly? A specific answer is far more useful than a capability deck. We reply within one business day.
Phone
(+84) 963 929 241Address
CirCO Dien Bien Phu - 222 Dien Bien Phu, Vo Thi Sau Ward, Ho Chi Minh, Vietnam