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, and 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.
Google vừa phát hành bản cập nhật Gemini Omni 1.1 Flash cho các nhà phát triển thông qua Google AI Studio và Gemini Enterprise Agent Platform. Khác với các
Is Agentic chấm hecigo.com 73/100. Bốn vòng vá đưa nó lên 100. Lỗi đắt nhất là một phép kiểm mà chính bài này từng lấy làm ví dụ về việc làm đúng.
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.
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, and every step has an exit. You pay a small amount, watch it run, and only then decide whether to continue.
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.
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.