DEV Community: Nventory

The metric we were optimising for was wrong. Here's what we measure now.

Nventory — Mon, 21 Sep 2026 11:55:34 +0000

For the first eight months of building Nventory we obsessed over sync speed.

p99 sync lag. Propagation time per channel. Webhook delivery rates. Time from order confirmation to every channel reflecting the updated stock count.

We got it to under 800 milliseconds on average. We were proud of that number.

Then a seller asked us something we didn't have a good answer to.

"How will I know when I can stop thinking about inventory?"

Not when will it be accurate. Not when will the oversells stop.

When can I stop thinking about it entirely.

We talked about sync speeds. She nodded politely and said: "That's still thinking about it."

The metric we were measuring vs the metric that mattered

javascript
// What we were measuring
const metrics = {
syncLagP99: '780ms',
propagationSuccessRate: '99.7%',
oversellRate: '0%',
webhookDeliveryRate: '99.9%'
};

// What she was asking us to measure
const metricThatActuallyMattered = {
weeksWithoutInventoryCrossingHerMind: 0 // we had no idea
};

We had built a tool that made inventory management faster and more accurate.

We hadn't built a tool that made it disappear from someone's mental load entirely.

Those are different products.

What "mental load" actually means technically

Mental load in a software context is the number of decisions a user has to consciously make to keep the system working correctly.

Every manual stock update is a decision.
Every cross-channel reconciliation is a decision.
Every "did this sync correctly" check is a decision.
Every low stock alert that requires a human to evaluate and act on is a decision.

We had eliminated the obvious decisions — the manual updates, the reconciliation, the oversell firefighting. But we hadn't eliminated the ambient ones. The background hum of "is everything okay" that runs constantly in an operator's head.

javascript
// Decisions we had eliminated
const eliminatedDecisions = [
'manually update stock after each sale',
'check each channel for sync failures',
'pause listings when stock hits zero',
'reconcile end of day inventory'
];

// Decisions we hadn't eliminated yet
const remainingMentalLoad = [
'check dashboard to confirm everything is fine',
'evaluate low stock alerts and decide action',
'verify that automations ran correctly',
'wonder if anything broke overnight'
];

// The second list is smaller but higher frequency
// It's what wakes operators up at 3am

The second list is what she meant when she said "that's still thinking about it."

What we built differently

The shift wasn't in the core sync architecture. That was already right.

It was in the notification layer and the automation layer.

Notifications that only fire when action is required — not to confirm normalcy

javascript
// What we were doing
async function sendInventoryAlert(sku, currentQty, threshold) {
if (currentQty < threshold) {
await notify({
message: ${sku} is below threshold. Current: ${currentQty},
action: 'Review inventory' // still requires human decision
});
}
}

// What we changed to
async function handleLowStock(sku, currentQty, threshold) {
if (currentQty < threshold) {
// Execute the action automatically if rule exists
const rule = await automationRules.getForSku(sku, 'low_stock');

if (rule) {
  await rule.execute({ sku, currentQty });
  // Only notify if execution failed or needs confirmation
  if (rule.requiresConfirmation) {
    await notify({ message: `Executed: ${rule.description}`, sku });
  }
  // Otherwise — silent execution. No notification. No decision required.
} else {
  // No rule exists — now it makes sense to notify
  await notify({
    message: `${sku} below threshold — no automation rule set`,
    action: 'Set up automation rule once, never think about this SKU again'
  });
}

}
}

The difference: notifications that fire when something needs a human are valuable. Notifications that fire to tell you a machine did its job are noise that keeps you thinking about the system.

Automations that encode decisions permanently

javascript
// The old model — alert then decide
// Low stock → alert → human evaluates → human acts → repeat next time

// The new model — decide once, automate forever
const automation = await automationBuilder.fromDescription(
"When Hoodie SKU drops below 20 units, pause listings on eBay and TikTok,
keep Shopify active, and alert the warehouse team — not me"
);

await workflowEngine.register(automation);

// The seller makes this decision once
// It runs automatically every time the condition is met
// They never think about this SKU again

The key phrase from the seller's perspective: "not me." The warehouse team needs to know. She doesn't. Building that distinction into the notification routing was the change that made inventory disappear from her mental load.

The new metric

Three months after rebuilding the notification and automation layer — she messaged us.

"I haven't thought about inventory in two weeks."

We added a metric to our internal dashboard.

javascript
const mentalLoadMetrics = {
// Proxy metrics for mental load reduction
automationCoverageRate: 'percentage of recurring decisions with automation rules',
notificationActionRate: 'percentage of notifications that require human action',
// Target: >95% of notifications require action
// If you're notifying for confirmations — you're creating mental load

supportTicketTopics: 'categorised by whether they represent a recurring decision',
// Recurring decisions that generate support tickets = unautomated mental load

dashboardOpenRate: 'how often sellers open dashboard vs how often they need to',
// Target: dashboard opened because something needs attention
// Not because seller is checking everything is okay
};

We still track sync speed. But the metric we actually care about is how long sellers go without thinking about inventory.

The best infrastructure is invisible. Not fast. Not accurate. Invisible.

The question for developers

What's the difference between the metric you're optimising for and the metric your users actually care about?

And how would you even know if those two things were different?

Worth exploring: nventory.io — free forever
Shopify App Store: apps.shopify.com/nventory

We evaluated 40+ inventory sync tools before building our own. Here's the architectural pattern that separates the good from the broken.

Nventory — Thu, 17 Sep 2026 10:20:54 +0000

Before building Nventory we spent three months evaluating every inventory sync tool in the market.

Not as potential customers. As engineers trying to understand why the problem remained unsolved despite dozens of tools claiming to solve it.

The pattern we found was consistent and damning.

Almost every tool was built on the same broken foundation.

The polling problem

javascript
// What almost every inventory sync tool does under the hood
setInterval(async () => {
const stock = await getSourceOfTruth();
await syncToAllChannels(stock);
}, 15 * 60 * 1000); // every 15 minutes

// The math nobody shows you
const windowsPerDay = (24 * 60) / 15; // 96
const ordersPerWindow = 500 / windowsPerDay; // ~5.2 at normal velocity
const ordersPerWindowPeak = ordersPerWindow * 10; // ~52 during a flash sale

// 52 orders processed against potentially stale cross-channel stock
// per 15-minute window
// during a flash sale
// with no channel knowing what the others have sold
// Result: predictable, preventable oversells

96 windows per day where channels disagree about stock. Every marketing page says "real-time sync." Every settings panel says "sync every 15 minutes."

These are not the same thing.

Why this happens

Polling is the default architecture because it's simple, predictable, and easy to reason about. Build a cron job. Pull current state. Push to channels. Done.

The failure mode is invisible at low volume. A 15-minute sync interval at 20 orders per day means each window processes 0.2 orders on average. The probability of a cross-channel conflict is negligible.

At 500 orders per day during a flash sale - the same architecture processes 52 orders per window against stale data. The failure mode is no longer negligible. It's inevitable.

The tools that got built at low-volume assumptions never got rearchitected when the volume assumptions changed.

The five architectural failures we found

No idempotency

javascript
// What happens when a webhook fires twice
// (which happens more than you think)

// Without idempotency
orderEventBus.on('order.confirmed', async (event) => {
await inventory.decrement(event.sku, event.qty);
// First delivery: stock goes from 10 to 9. Correct.
// Second delivery (retry): stock goes from 9 to 8. Wrong.
// Silent inventory corruption. Nobody notices until stocktake.
});

// With idempotency
orderEventBus.on('order.confirmed', async (event) => {
if (await idempotencyStore.exists(event.orderId)) return;
await inventory.decrement(event.sku, event.qty);
await idempotencyStore.mark(event.orderId);
// Retry handled safely. State correct.
});

No optimistic locking

Two orders hitting the same last SKU from different channels simultaneously. Without locking, both decrement independently. Both succeed. One oversell.

javascript
// Without locking — race condition
const stock = await inventory.get(sku); // both reads return 1
await inventory.set(sku, stock - 1); // both writes set to 0
// Result: 2 orders fulfilled for 1 unit

// With optimistic locking
const result = await inventory.compareAndSwap(sku, {
expectedVersion: current.version,
newQty: current.qty - 1
});
if (!result.success) throw new ConcurrentUpdateError();
// One succeeds, one retries or fails safely

Silent propagation failures

javascript
// What most tools do when a channel update fails
try {
await channel.updateInventory(sku, qty);
} catch (error) {
console.log('Update failed'); // logged and forgotten
// Channel now shows wrong stock
// Nobody knows until a seller asks why their eBay shows 10 units they don't have
}

// What you actually need
try {
await channel.updateInventory(sku, qty);
} catch (error) {
await deadLetterQueue.push({
channel: channel.id,
sku,
qty,
error: error.message,
retryAt: Date.now() + backoffMs(failureCount)
});
// Failure is captured, retried, and surfaced — never silently dropped
}

No verification

javascript
// Trusting the API response
const response = await channel.setInventory(sku, qty);
if (response.status === 200) return true; // assumed correct

// The problem: WooCommerce returns 200 with silent validation errors
// eBay returns Ack: 'Success' with errors in a separate array
// Amazon queues updates that aren't immediately applied

// Verify every write
const response = await channel.setInventory(sku, qty);
const verification = await channel.getInventory(sku);
if (verification.qty !== qty) {
throw new InventoryMismatchError(sku, qty, verification.qty);
}

No canonical data model

Every channel has a different data model. SKUs that are strings on Shopify are integers elsewhere. Variant attributes map differently across platforms. Without a normalisation layer, field mapping becomes the source of truth — and field mapping errors become inventory errors.

javascript
// Without canonical model — direct channel-to-channel sync
// Shopify variant → Amazon mapping → eBay mapping → WooCommerce mapping
// Each mapping is a potential error source
// Errors compound across the chain

// With canonical model
const internalProduct = normalise(shopifyProduct); // one normalisation
await Promise.all([
amazon.updateFromInternal(internalProduct),
ebay.updateFromInternal(internalProduct),
woocommerce.updateFromInternal(internalProduct)
]); // each channel maps from the same canonical source

What the correct architecture looks like

javascript
// Event-driven with all five failure modes addressed
orderEventBus.on('order.confirmed', async ({ sku, qty, channel, orderId }) => {
// 1. Idempotency
if (await idempotencyStore.exists(orderId)) return;

// 2. Optimistic locking
const result = await inventory.decrementWithLock(sku, qty);
if (!result.success) {
await oversellPrevention.handle({ sku, channel, orderId });
return;
}

// 3. Propagate with DLQ for failures
await Promise.allSettled(
connectedChannels
.filter(ch => ch.id !== channel)
.map(ch =>
ch.updateInventory(sku, result.newQty)
.catch(err => deadLetterQueue.push({ channel: ch.id, sku, err }))
)
);

// 4. Verify writes
const verifications = await Promise.all(
connectedChannels.map(ch => ch.getInventory(sku))
);
verifications.forEach(v => {
if (v.qty !== result.newQty) {
alerting.warn('Inventory mismatch detected', { sku, channel: v.channelId });
}
});

// 5. Audit trail
await auditLog.record({ sku, qty, channel, orderId, result, timestamp: Date.now() });

await idempotencyStore.mark(orderId);
});

Sync lag: milliseconds. Oversell probability: near zero. Failed propagations: captured and retried. Silent failures: impossible.

What we built

This is the architecture Nventory is built on event-driven sync across 40+ channels with idempotency, optimistic locking, DLQ propagation, write verification, and canonical data model throughout.

The five failure modes above aren't theoretical. We found all five in tools that sellers were actively using and paying for.

→ nventory.io — free forever
→ apps.shopify.com/nventory — Shopify App Store

The silent bug that taught us to never trust an API success response

Nventory — Thu, 20 Aug 2026 12:01:57 +0000

Three weeks after launching Nventory we had a silent bug.

Inventory was updating correctly everywhere.

Except one seller's WooCommerce store.

Every sync completed successfully. Every log showed green. Every API call returned 200. The seller's stock was quietly wrong for eleven days before anyone noticed.

The bug wasn't in the sync layer. It was in the verification step we hadn't built yet.

javascript
// What we were doing
async function updateInventory(channel, sku, qty) {
const response = await channel.setInventory(sku, qty);

if (response.status === 200) {
await auditLog.record({ sku, qty, channel: channel.id, status: 'success' });
return true; // assumed success
}
}

// The problem
// WooCommerce was returning 200 with a silent validation error
// The inventory wasn't updating
// The log showed green
// Nobody knew for eleven days

We were trusting the API response instead of reading back the actual state.

The fix

javascript
// What we do now
async function updateInventory(channel, sku, qty) {
const response = await channel.setInventory(sku, qty);

if (response.status !== 200) {
throw new ChannelAPIError(channel.id, response);
}

// Read back — verify the write actually took effect
const verification = await channel.getInventory(sku);

if (verification.qty !== qty) {
// The API said success. The state disagrees.
await deadLetterQueue.push({
channel: channel.id,
sku,
expectedQty: qty,
actualQty: verification.qty,
retryAt: Date.now() + backoffMs(0)
});

throw new InventoryMismatchError(sku, qty, verification.qty);

}

await auditLog.record({
sku,
qty,
channel: channel.id,
status: 'verified', // not just 'success'
verifiedAt: Date.now()
});

return true;
}

One word change in the audit log — from success to verified — that represents an entirely different level of confidence in the data.

Why this happens more than you think

Most channel APIs have at least one scenario where they return a success response without actually completing the operation.

WooCommerce returns 200 when a product update hits a validation constraint it doesn't surface in the response body. Amazon SP-API returns success for inventory updates that are silently queued rather than immediately applied. eBay returns Ack: Success with errors buried in a separate Errors array that most implementations never check.

javascript
// eBay — the classic trap
const response = await ebayAPI.reviseInventoryStatus(params);

// Naive check
if (response.Ack === 'Success') return true; // WRONG

// Correct check
if (response.Errors && response.Errors.length > 0) {
throw new EbayAPIError(response.Errors);
}

// Then verify
const verification = await ebayAPI.getItem(itemId);
if (verification.Quantity !== expectedQty) {
throw new InventoryMismatchError();
}

The broader principle

Every external write in a distributed system should be followed by a read that confirms the state changed correctly.

This is especially true for inventory data where the cost of silent failure is immediate and measurable — a seller shows stock that doesn't exist, an oversell happens, a customer gets a cancellation email.

javascript
// The pattern we now apply to every channel integration
class VerifiedInventoryUpdate {
async execute(channel, sku, qty, maxRetries = 3) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
try {
// Write
await channel.setInventory(sku, qty);

    // Verify
    const actual = await channel.getInventory(sku);

    if (actual.qty === qty) {
      await this.auditLog.record({ sku, qty, channel: channel.id, status: 'verified' });
      return { success: true, verified: true };
    }

    // Write succeeded, verification failed — retry
    await sleep(backoffMs(attempt));

  } catch (error) {
    if (attempt === maxRetries - 1) {
      // All retries exhausted — dead letter queue
      await this.dlq.push({ channel: channel.id, sku, qty, error: error.message });
      throw error;
    }
    await sleep(backoffMs(attempt));
  }
}

}

backoffMs(attempt) {
return Math.min(1000 * Math.pow(2, attempt), 30000);
}
}

What changed after this bug

Three specific things:

Every write has a read-back. Not just for WooCommerce. Every channel. Every time. The extra API call is worth it.

Audit logs say "verified" not "success." The distinction matters. Success means the API returned 200. Verified means the state actually changed. We only log verified now.

Silent failures go to DLQ immediately. A mismatch between expected and actual state isn't an error to retry inline — it's a failure to investigate. It goes to the dead letter queue with full context so it can be resolved without data loss.

This is the architecture we've built into every one of the 40+ channel integrations at Nventory — because when you're syncing inventory across Amazon, Shopify, WooCommerce, Flipkart, and eBay simultaneously, a single silent failure can corrupt stock counts across every connected channel before anyone notices.

The eleven days taught us one thing above everything else:

Green logs are not the same as correct data.

Build verification into every write. Assume every API will silently fail you at least once. Because it will and you won't know until eleven days later when a seller asks why their stock is wrong.

Trust nothing. Verify everything.

We're building Nventory — multichanial inventory and order management, free forever. Also available on the Shopify App Store if you're building for multichannel sellers.

Questions welcome in the comments — happy to go deeper on any of the verification patterns.

We built 40+ integrations. Here's what nobody tells you.

Nventory — Mon, 10 Aug 2026 11:02:55 +0000

Everyone talks about building integrations like it's a solved problem.

Connect to the API. Map the fields. Ship it.

We've built 40+ integrations at Nventory - Amazon, Shopify, Flipkart, eBay, WooCommerce, TikTok Shop, FedEx, DHL, QuickBooks, and dozens more. Here's what actually happens when you do this at scale.

Every API has a personality

And some of them have serious personality disorders.

Shopify's API is clean, well-documented, and mostly behaves the way you expect. Amazon's SP-API is powerful but has the documentation of a legal contract written in 2003. Flipkart's API works perfectly until it doesn't, with error messages that tell you nothing useful.

javascript
// Shopify error — actually helpful
{
"errors": {
"inventory_item_id": ["can't be blank"]
}
}

// Amazon SP-API error — less helpful
{
"code": "InvalidInput",
"message": "Request has invalid parameters",
"details": ""
}

// Flipkart error — chaotic neutral
{
"status": "SUCCESS",
"statusCode": "200",
"error": "ITEM_NOT_FOUND"
}

That last one is real. Status 200. Error: ITEM_NOT_FOUND. We spent two days on that.

The lesson: Never trust the HTTP status code alone. Parse the response body. Every time. Without exception.

Rate limits will destroy you if you're not careful

Every API has rate limits. Most APIs don't tell you when you're approaching them, they just start failing.

Amazon SP-API uses a token bucket algorithm. Each endpoint has its own rate limit, restore rate, and burst limit. Getting this wrong means your sync stops working during peak trading periods — exactly when you need it most.

javascript
// Naive approach will get you rate limited
async function syncAllProducts(products) {
await Promise.all(products.map(p => amazonAPI.updateInventory(p)));
// 500 products = 500 simultaneous requests
// Rate limit hit in seconds
}

// Better approach — token bucket with backoff
class RateLimiter {
constructor(tokensPerSecond, burst) {
this.tokens = burst;
this.maxTokens = burst;
this.tokensPerSecond = tokensPerSecond;
this.lastRefill = Date.now();
}

async acquire() {
this.refill();

if (this.tokens < 1) {
  const waitTime = (1 / this.tokensPerSecond) * 1000;
  await sleep(waitTime);
  return this.acquire();
}

this.tokens -= 1;

}

refill() {
const now = Date.now();
const elapsed = (now - this.lastRefill) / 1000;
this.tokens = Math.min(
this.maxTokens,
this.tokens + elapsed * this.tokensPerSecond
);
this.lastRefill = now;
}
}

// Each API gets its own rate limiter
const amazonLimiter = new RateLimiter(2, 10); // 2 per second, burst of 10
const shopifyLimiter = new RateLimiter(4, 40); // 4 per second, burst of 40

The lesson: Build rate limiting before you need it. Retrofitting it after you've been blocked is significantly more painful.

Webhook delivery is not guaranteed

This one cost us more debugging hours than anything else.

Every platform says they deliver webhooks reliably. What they mean is they attempt delivery reliably. Network issues, server restarts, brief downtime — any of these can cause a webhook to fail silently.

The naive implementation:

javascript
// What most people build first
app.post('/webhooks/shopify/orders', async (req, res) => {
await processOrder(req.body);
res.status(200).send('OK');
});

// Problem: if processOrder fails or times out,
// Shopify retries and you process the same order twice

The production implementation:

javascript
// What you actually need
app.post('/webhooks/shopify/orders', async (req, res) => {
// Acknowledge immediately before processing
res.status(200).send('OK');

const webhookId = req.headers['x-shopify-webhook-id'];

// Idempotency check - have we processed this before?
if (await idempotencyStore.exists(webhookId)) {
return; // Duplicate delivery - safe to ignore
}

try {
await processOrder(req.body);
await idempotencyStore.mark(webhookId);
} catch (error) {
// Failed processing goes to dead letter queue
// Never silently dropped
await deadLetterQueue.push({
webhookId,
payload: req.body,
error: error.message,
retryAt: Date.now() + backoffMs(0)
});
}
});

Three things here:

Acknowledge immediately - slow processing causes retries
Idempotency keys - duplicate deliveries are handled safely
Dead letter queue - failed processing never gets silently dropped

The lesson: Assume every webhook will be delivered at least twice. Build accordingly from day one.

Field mapping is where integrations go to die

Every platform has its own data model. SKUs that are strings on Shopify are integers on some marketplaces. Product titles have different character limits. Variant attributes that map cleanly on one platform have no equivalent on another.

javascript
// Shopify product variant
{
id: 123456789,
sku: "HOODIE-BLK-M",
inventory_quantity: 47,
option1: "Black",
option2: "Medium",
option3: null
}

// Amazon equivalent - completely different model
{
ASIN: "B08XYZ123",
SellerSKU: "HOODIE-BLK-M",
Quantity: 47,
// Colour and size live in a completely different API call
// Under a different authentication scope
// With a different rate limit
}

// eBay equivalent - different again
{
ItemID: "123456789012",
SKU: "HOODIE-BLK-M",
Quantity: 47,
Variations: {
VariationSpecifics: [
{ Name: "Colour", Value: "Black" },
{ Name: "Size", Value: "Medium" }
]
}
}

We built a normalisation layer that maps every platform's data model to our internal schema. Every integration writes to and reads from the normalised model not directly to each other.

javascript
// Internal normalised schema
const internalProduct = {
internalId: "prod_abc123",
sku: "HOODIE-BLK-M",
quantity: 47,
attributes: {
color: "Black",
size: "Medium"
},
channelIds: {
shopify: "123456789",
amazon: "B08XYZ123",
ebay: "123456789012"
}
};

// Each integration maps to/from this schema
// Never directly to each other

The lesson: Build a canonical internal data model before writing your first integration. Retrofitting one after you have 10 integrations is a multi-month project.

Silent failures are the worst failures

A broken integration that throws errors is easy to debug. An integration that silently succeeds while doing the wrong thing is a nightmare.

We had a bug in our eBay integration for three weeks where inventory updates were returning 200 OK but not actually updating the listing quantity. No error. No log entry. Just wrong data silently propagating.

javascript
// The bug
async function updateEbayInventory(sku, qty) {
const response = await ebayAPI.reviseInventoryStatus({
ItemID: await getEbayItemId(sku),
Quantity: qty
});

if (response.Ack === 'Success') {
return true; // Assumed success
}
// Didn't check response.Errors
// eBay returns Ack: 'Success' with errors in some cases
}

// The fix
async function updateEbayInventory(sku, qty) {
const response = await ebayAPI.reviseInventoryStatus({
ItemID: await getEbayItemId(sku),
Quantity: qty
});

if (response.Errors && response.Errors.length > 0) {
throw new EbayAPIError(response.Errors);
}

// Verify the update actually took effect
const verification = await ebayAPI.getItem(await getEbayItemId(sku));
if (verification.Quantity !== qty) {
throw new InventoryMismatchError(sku, qty, verification.Quantity);
}

return true;
}

The lesson: Verify, don't trust. After every write operation — read back and confirm the state changed correctly.

Every API changes without warning

We've had integrations break overnight because a platform deprecated a field, changed authentication, or updated their data model without announcing it.

Build monitoring that detects integration drift before your users do:

javascript
// Integration health checks — run every 5 minutes
async function checkIntegrationHealth(channel) {
try {
// Test authentication
await channel.authenticate();

// Test read operation
const testProduct = await channel.getProduct(channel.testProductId);
if (!testProduct) throw new Error('Test product not found');

// Test write operation (with rollback)
const originalQty = testProduct.quantity;
await channel.updateInventory(channel.testProductId, originalQty);

metrics.record('integration_health', { channel: channel.id, status: 'healthy' });

} catch (error) {
metrics.record('integration_health', { channel: channel.id, status: 'degraded' });
alerting.warn(Integration degraded: ${channel.id}, { error: error.message });
}
}

The lesson: Monitor your integrations actively. Don't wait for a seller to tell you something is broken.

What 40+ integrations taught us

The technical patterns are learnable. The real lessons are cultural:

→ Assume every external API is unreliable until proven otherwise
→ Build idempotency before you need it — retrofitting is painful
→ Verify every write — trust nothing
→ Silent failures are worse than loud ones
→ Your canonical data model is your most important architectural decision
→ Rate limits will bite you at the worst possible moment

The integrations that work in production aren't the ones written fastest. They're the ones written with the most paranoia.

We're building Nventory on these patterns — event-driven sync across 40+ channels, with idempotency, verification, and active health monitoring built in throughout.

Why Your Inventory Sync Breaks Under Load And the Architecture That Fixes It

Nventory — Wed, 05 Aug 2026 10:50:55 +0000

Most cloud inventory systems are built the same way: a cron job polls each channel's API on a schedule, fetches new orders, updates stock counts, and repeats. It works at 50 orders a day. At 500 it produces race conditions that cause overselling nobody notices until a customer complains.

The fix is architectural. Here's the problem in precise terms — and the event-driven pattern that solves it.

The race condition in one scenario

You have 1 unit of SKU-X. At 11:47:03, a customer buys it on Shopify. At 11:47:04, a different customer buys it on Amazon. Your polling job last ran at 11:45. It runs again at 12:00.

In that 13-minute window, both orders confirm. Both customers get confirmation emails. You have 1 unit and 2 confirmed orders.

The system didn't throw an error. It worked exactly as designed. The design is wrong.

Why polling can't fix this

The instinct is to shorten the polling interval. Poll every minute instead of every 15. But polling every minute means 60 API calls per channel per hour per SKU which hits rate limits before it solves the race condition. And even at 1-minute polling, a concurrent sale in the same minute still oversells.

The race condition isn't a polling frequency problem. It's a consistency model problem. Polling creates an eventually consistent system. For inventory, you need strong consistency - a guarantee that when a unit sells anywhere, it is unavailable everywhere before the next sale can confirm.

The webhook-driven architecture

Instead of your system asking each channel "anything new?" on a schedule, each channel tells your system the moment something happens.

javascript
// Register webhooks on channel connect
async function registerWebhooks(shop, accessToken) {
const webhooks = [
{ topic: 'orders/create', address: ${BASE_URL}/webhooks/shopify/orders },
{ topic: 'inventory_levels/update', address: ${BASE_URL}/webhooks/shopify/inventory }
];

for (const webhook of webhooks) {
await shopifyAPI.post('/webhooks.json', { webhook }, {
headers: { 'X-Shopify-Access-Token': accessToken }
});
}
}

// Webhook handler — respond fast, process async
app.post('/webhooks/shopify/orders', async (req, res) => {
// Always verify signature first
const hmac = req.headers['x-shopify-hmac-sha256'];
if (!verifyShopifySignature(hmac, req.rawBody, process.env.SHOPIFY_SECRET)) {
return res.status(401).send('Unauthorized');
}

// Respond immediately — Shopify retries if no response within 5s
res.status(200).send('OK');

// Process asynchronously
await orderQueue.add('process-order', {
channel: 'shopify',
order: req.body
});
});

Respond to the webhook immediately. Process asynchronously. If you do heavy processing synchronously, you'll miss the response window and the channel will retry producing duplicate events.

Atomic inventory decrements

Webhook-driven intake solves the awareness problem. Atomic decrements solve the consistency problem.

javascript
async function decrementInventory(sku, quantity, orderId) {
// Idempotency check webhook retries can produce duplicate events
const alreadyProcessed = await redis.get(order:${orderId});
if (alreadyProcessed) {
console.log(Order ${orderId} already processed — skipping);
return;
}

// Atomic decrement with availability check
// Using MongoDB findOneAndUpdate for atomicity
const result = await db.inventory.findOneAndUpdate(
{
sku,
availableQuantity: { $gte: quantity } // Only decrement if enough stock
},
{
$inc: { availableQuantity: -quantity },
$push: {
reservations: { orderId, quantity, reservedAt: new Date() }
}
},
{ returnDocument: 'after' }
);

if (!result) {
// Insufficient stock publish event for oversell prevention
await eventBus.publish('inventory.insufficient', { sku, quantity, orderId });
return;
}

// Mark order as processed (idempotency)
await redis.setex(order:${orderId}, 86400, 'processed');

// Propagate new stock level to all channels
await propagateStockUpdate(sku, result.availableQuantity);
}

The $gte: quantity check and the atomic findOneAndUpdate together prevent the race condition at the database level. Two concurrent requests for the last unit - the second one finds availableQuantity: 0 after the first decrements it, and correctly returns no result.

Propagating back to all channels

javascript
async function propagateStockUpdate(sku, newQuantity) {
const channelMappings = await db.inventoryMappings.find({ sku });

// Update all channels in parallel don't block on one channel's failure
const results = await Promise.allSettled(
channelMappings.map(async (mapping) => {
try {
await updateChannelInventory(mapping.channel, mapping.externalId, newQuantity);
} catch (err) {
// Failed updates go to retry queue — never dropped
await retryQueue.add('inventory-update', {
channel: mapping.channel,
sku,
newQuantity,
attempts: 0
}, {
attempts: 5,
backoff: { type: 'exponential', delay: 1000 }
});
}
})
);

return results;
}

Promise.allSettled ensures one channel failing doesn't block others. Exponential backoff retry means a temporary API outage doesn't permanently desync a channel's inventory.

The result

This is the architecture that proper inventory management software cloud based implements under the hood - webhook-driven intake, atomic decrements with idempotency, and parallel propagation with retry safety. The oversell window shrinks from 15 minutes to near zero. Concurrent orders for the same last unit are handled correctly at the database level. Channel failures are retried rather than dropped.

If you'd rather not build this yourself, Nventory ships this architecture across 30+ channels out of the box - free plan available.

How to Build a Multichannel Order Manager Event Pipeline That Actually Scales

Nventory — Wed, 22 Jul 2026 05:52:21 +0000

Most multichannel order backends fail the same way: every channel gets its own polling job, its own data model, and its own sync schedule. It works at 10 orders a day. At 500 it produces race conditions, inventory drift, and duplicate fulfillments nobody notices until a customer complains.

The fix is an event-driven pipeline with a unified data model. Here's the architecture that scales.

The core problem with channel-per-silo architecture

When each channel has its own sync job, inventory state is never globally consistent. Channel A sold a unit at 11:52. Channel B's sync runs at 12:00. In that 8-minute window, Channel B can sell the same unit. Now you have two confirmed orders for one item.

The race condition isn't a bug you can patch — it's structural. The only fix is a single inventory state that all channels read from and write to atomically.

Event-driven pipeline architecture

javascript
// Unified order event schema — normalize all channels to this
const OrderEvent = {
eventId: 'uuid', // idempotency key
channel: 'shopify|amazon|ebay|tiktok|walmart',
externalOrderId: 'string',
placedAt: 'ISO8601',
lineItems: [
{
sku: 'string',
quantity: 'number',
warehouseId: 'string|null' // null = needs routing
}
],
customer: {},
fulfillmentRequired: 'boolean'
};

Every channel webhook maps its native payload to this schema before anything else touches it. Downstream systems only ever see OrderEvent never raw channel payloads.

Webhook handlers per channel

javascript
// Shopify webhook handler
app.post('/webhooks/shopify/orders/create', async (req, res) => {
verifyShopifySignature(req); // always verify first

const event = normalizeShopifyOrder(req.body);
await eventQueue.publish('order.created', event);

res.status(200).send('OK'); // respond fast, process async
});

// Amazon webhook handler — same pipeline, different normalizer
app.post('/webhooks/amazon/orders/create', async (req, res) => {
verifyAmazonSignature(req);

const event = normalizeAmazonOrder(req.body);
await eventQueue.publish('order.created', event);

res.status(200).send('OK');
});

Key rule: respond to the webhook immediately, process asynchronously. Channels retry if you don't respond within a few seconds — slow processing causes duplicate events.

Inventory decrement with optimistic locking

javascript
async function decrementInventory(sku, quantity, eventId) {
// Idempotency — don't decrement twice for the same event
const processed = await db.processedEvents.findOne({ eventId });
if (processed) return;

const result = await db.inventory.findOneAndUpdate(
{ sku, quantity: { $gte: quantity } }, // only if enough stock
{ $inc: { quantity: -quantity } },
{ returnDocument: 'after' }
);

if (!result) {
await eventQueue.publish('order.insufficient_stock', { sku, quantity, eventId });
return;
}

// Propagate new stock level to all channels immediately
await propagateStockUpdate(sku, result.quantity);
await db.processedEvents.create({ eventId, processedAt: new Date() });
}

The $gte check and atomic update together prevent overselling at the database level — no amount of concurrent orders can decrement below zero.

Stock propagation back to channels

javascript
async function propagateStockUpdate(sku, newQuantity) {
const channels = await db.connectedChannels.find({ sku });

await Promise.allSettled(
channels.map(channel =>
updateChannelStock(channel, sku, newQuantity)
.catch(err => retryQueue.add({ channel, sku, newQuantity }, { attempts: 5 }))
)
);
}

Promise.allSettled ensures one channel failing doesn't block others. Failed updates go into a retry queue with exponential backoff never dropped.

The result

This pipeline is what a proper multichannel order manager implements under the hood unified event schema, atomic inventory decrements, idempotent processing, and parallel channel propagation with retry safety.

If you'd rather not build this yourself, Nventory ships this architecture out of the box across 30+ channels - webhook-driven, idempotent, retry-safe, free plan available.

Unpopular opinion: free is an underrated business model in SaaS and we went all in on it

Nventory — Tue, 21 Jul 2026 10:03:33 +0000

Every SaaS business is trying to figure out how to charge more.

Higher plans. Usage-based pricing. Per-seat models. Annual lock-ins. Features gated behind tiers that exist purely to create upgrade pressure.

We went the other direction.

Nventory — multichannel inventory and order management across 40+ channels — is free. Permanently. Not a trial. Not freemium with the useful features locked. The full platform. Free forever.

This post is about why we made that decision, what changed when we did, and the honest business thinking behind it.

The SaaS pricing orthodoxy

The standard SaaS playbook is well documented.

Free trial to demonstrate value. Paid plans with usage limits that create natural upgrade pressure. Annual pricing with a discount to improve cash flow. Enterprise tier for large accounts. Referral programs with credits to drive virality.

This works. Lots of companies have built significant businesses on exactly this model.

The problem is it optimises for revenue extraction before value has been fully demonstrated. Every interaction with a prospect or new user is filtered through "are they going to pay?" before "are we actually solving their problem?"

What we noticed building Nventory

We ran a 14-day trial model for the first several months.

Here's what we kept observing:

Trial users didn't integrate properly. Fourteen days isn't enough to fully connect 5+ channels, set up automations, and experience the value of real-time sync during a high-velocity sales period. Most trial users were evaluating features rather than experiencing outcomes.

Churn happened before value was demonstrated. Sellers who churned during or after trial weren't churning because the product failed them. They were churning because the integration wasn't complete enough for them to know whether it worked.

The feedback signal was noisy. Users were evaluating cost-vs-features rather than problem-vs-solution. The product conversations were about pricing tiers rather than operational outcomes.

The sellers who needed it most couldn't justify the cost. A seller managing 500 orders per day across 5 channels — absorbing oversells, reconciling spreadsheets on Sunday mornings, logging into five dashboards every day — is the exact seller Nventory is built for. They're also frequently the seller with the least budget for another SaaS subscription.

What changed when we went free

Three specific things changed that we didn't fully anticipate.

The integration depth increased dramatically

Without trial pressure, sellers connect everything properly. They take the time to map their full channel set, configure routing rules, and build automations for their actual workflows. By the time they're using Nventory seriously, it's deeply embedded in how they operate.

This is the opposite of what happens with a 14-day trial where the clock is ticking.

The feedback quality improved significantly

javascript
// Trial user feedback (paraphrased)
"Is feature X included in the paid plan?"
"Will the price change if I add more channels?"
"What happens to my data if I don't upgrade?"

// Free user feedback (paraphrased)
"The automation builder doesn't handle this edge case in my workflow"
"The routing logic needs a fallback when my primary warehouse is out of stock"
"Can I get webhook notifications when sync lag exceeds a threshold?"

The second set of feedback makes the product better. The first set is noise generated by pricing friction.

Trust compounded differently

When sellers recommend Nventory it's because it solved a problem — not because they want referral credit. The recommendation is cleaner. The conversion rate of referred users is higher because they're coming in with genuine social proof rather than incentivised referral.

The honest business thinking

Free needs a model. We're not naive about this.

Here's how we think about it:

Distribution is the hardest problem in early-stage SaaS. Free removes the largest friction point in distribution — the payment decision. Getting sellers to try something free is significantly easier than getting them to pay before they've experienced value.

Operational software has high switching costs once embedded. An inventory management platform that's connected to 8 channels, has 15 automations running, and is processing 500 orders per day is not a tool sellers switch away from lightly — regardless of pricing. The value of being that embedded is significant.

The ecommerce operations market is large enough that even a small conversion rate on a large free base produces meaningful revenue. We don't need every free user to convert to sustain the business. We need a fraction of them to want capabilities that justify a paid tier.

Brand built on genuine value is more durable than brand built on marketing spend. Sellers who love Nventory because it's genuinely free and genuinely works talk about it in communities, recommend it to other sellers, and create the kind of organic growth that's difficult to manufacture with a paid acquisition budget.

What the business model actually looks like

Free tier: full platform. No artificial limits on channels, orders, or features.

Future paid tiers: enterprise capabilities — dedicated support SLAs, custom integrations, advanced analytics, white-label options for agencies managing multiple seller accounts. Things that genuinely require resources to deliver rather than features artificially held back to create upgrade pressure.

The distinction matters. We're not planning a free-to-paid conversion where the free tier degrades over time to push upgrades. We're planning to build genuinely premium capabilities on top of a genuinely free foundation.

Whether this works as a long-term business model — we'll find out. But the early signals are better than the trial model produced.

The developer's perspective on free

There's something worth saying specifically for developers building products.

The SaaS pricing orthodoxy was developed by people optimising for revenue metrics. Conversion rate from trial to paid. Monthly recurring revenue. Net revenue retention. Annual contract value.

These are valid metrics. They're also metrics that can be optimised at the expense of product quality, user trust, and genuine problem-solving.

The alternative optimisation target — how deeply embedded is this product in how our users actually work — produces different decisions. Decisions that look worse on a revenue dashboard in year one and significantly better in year three.

javascript
// Revenue-first optimisation
const objective = maximise(MRR);
const constraints = {
trialConversion: '>15%',
churn: '<5% monthly',
CAC: '<3x LTV'
};

// Outcome: features gated, trial pressure high,
// feedback noisy, trust fragile

// Value-first optimisation

const objective = maximise(integrationDepth * userCount);
const constraints = {
genuineProblemSolved: true,
switchingCostCreated: true,
organicGrowthEnabled: true
};

// Outcome: full features available, integration complete,
// feedback clean, trust compounding

We chose the second optimisation target. The revenue will follow the value — or it won't, and we'll have learned something important.

Where we are right now

Nventory is free. Permanently.

→ Real-time inventory sync across 40+ channels in under 5 seconds
→ AI automation — describe workflows in plain English
→ Smart order routing across FBA, 3PLs, and owned locations
→ 40+ native integrations — no middleware
→ Mobile apps on App Store and Play Store
→ Shopify App Store — apps.shopify.com/nventory

The question for the dev.to community

Two things I'm genuinely curious about:

Is free a real business model or a growth hack with a delayed paywall?

The cynical take: every "free forever" product eventually degrades the free tier or gets acquired and paywalls everything. The optimistic take: some products genuinely sustain on a freemium model with premium tiers that justify themselves.

Where do you stand?

What would make you trust a free product more?

Open source? Transparent pricing roadmap? Revenue disclosure? Something else?

Drop your thoughts below — this is a decision we're actively living with and genuinely curious how other builders think about it.

Why Polling Kills Your Multichannel Selling Architecture (And What to Do Instead)

Nventory — Tue, 21 Jul 2026 05:31:23 +0000

Most multichannel ecommerce backends are built the same way: a cron job polls each channel's API every 10–15 minutes, syncs inventory and moves on. It works at low volume. At scale it silently destroys you.

Here's why, and how webhook-driven architecture fixes it.

The polling problem in one scenario

You sell on Shopify, Amazon, and eBay. You have 3 units left of your best-selling SKU. At 11:52pm three customers buy simultaneously — one per channel. Your polling job last ran at 11:45. It runs again at 12:00. By then all three orders are confirmed. You have 3 oversells, 3 cancellation emails, and 2 marketplace penalties. Nothing threw an error. Everything "worked."

Webhook-driven sync fixes the race condition

Instead of your system asking each channel "anything new?" on a schedule, each channel tells your system the moment something happens.

javascript
// Register webhook on channel connect
await shopify.webhook.create({
topic: 'orders/create',
address: 'https://your-oms.com/webhooks/shopify',
format: 'json'
});

// Handle incoming webhook
app.post('/webhooks/shopify', async (req, res) => {
const order = req.body;

// Verify signature first
const hmac = req.headers['x-shopify-hmac-sha256'];
if (!verifySignature(hmac, req.rawBody)) {
return res.status(401).send('Unauthorized');
}

// Decrement inventory across all channels immediately
await inventory. decrementAllChannels (order.line_items);

res.status(200).send('OK');
});

Every channel fires its webhook the moment an order lands. Your system decrements inventory across all other channels within seconds. The oversell window shrinks from 15 minutes to near zero.

Handle failures properly

Webhooks fail. Channels retry but your system needs to be idempotent:

javascript
async function processOrder(orderId, lineItems) {
// Idempotency check — don't process the same order twice
const existing = await db.orders.findOne({ externalId: orderId });
if (existing) return;

await db.orders.create({ externalId: orderId, status: 'processing' });
await inventory.decrementAllChannels(lineItems);
}

The result

Webhook-driven multichannel selling infrastructure means inventory accuracy in seconds not minutes, zero recurring API polling load, and race conditions eliminated at the architectural level not patched around.

If you'd rather not build this yourself, Nventory handles exactly this architecture across 30+ channels out of the box - webhook-driven, idempotent, retry-safe. Free plan available.

How WooCommerce REST API Powers External Order Management (And Why It Beats Plugins)

Nventory — Thu, 16 Jul 2026 06:14:09 +0000

If you've built or maintained a WooCommerce store at scale, you've probably hit the moment where the built-in order management stops being enough. More channels, more warehouses, more SKUs and suddenly wp-admin is the bottleneck instead of the solution.

The good news is WooCommerce's REST API and webhook system are genuinely well-designed for connecting external tools. The bad news is most store owners don't know how to evaluate whether the tool they're connecting actually uses those capabilities properly or just bolts a heavy plugin onto their server and calls it integration.

Here's how the architecture works, what good external order management looks like from a technical standpoint, and what to check before you connect anything to your WooCommerce store.

WooCommerce REST API: what's actually available
WooCommerce ships with a full REST API covering orders, products, customers, inventory, refunds, and shipping. It follows standard REST conventions with JSON responses, supports OAuth 1.0a and application passwords for authentication, and is versioned (currently v3) so breaking changes don't silently break your integrations.

The endpoints you care about for order management:
GET /wp-json/wc/v3/orders — list orders with filters
GET /wp-json/wc/v3/orders/{id} — single order detail
PUT /wp-json/wc/v3/orders/{id} — update order status, tracking
GET /wp-json/wc/v3/products — product catalog
PUT /wp-json/wc/v3/products/{id} — update stock levels
GET /wp-json/wc/v3/stock — inventory levels
POST /wp-json/wc/v3/refunds — issue refunds programmatically

Rate limits aren't enforced by WooCommerce itself — they depend on your hosting environment. On shared hosting, aggressive polling against these endpoints will cause server slowdowns. On a VPS, you have more headroom, but it still adds unnecessary load.

Webhooks: the right way to receive order events
Rather than polling the REST API on a schedule, WooCommerce supports webhooks that fire on specific events. You register a webhook URL in WooCommerce settings (or programmatically via the API), and WooCommerce POSTs a JSON payload to that URL whenever the event occurs.

The events that matter for order management:
order.created — fires when a new order is placed
order.updated — fires on any order status change
order.deleted — fires on order deletion
product.updated — fires when product/stock data changes
customer.created — fires on new customer registration
The payload includes the full order object — line items, customer data, shipping address, payment method, applied coupons, custom meta — everything an external system needs to process and route the order without making a follow-up API call.

A webhook-driven external OMS receives this payload, processes it on its own servers, updates its internal state, routes the order to the right warehouse, and pushes a stock update back to WooCommerce via the REST API. Your WordPress server handles exactly two things: firing the webhook and receiving the stock update. Everything else happens externally.

Compare that to a polling-based plugin: it runs a cron job on your WordPress server every N minutes, queries the orders endpoint, diffs the results against its local state, processes new orders and writes back to the database all on your server, all consuming your hosting resources, all adding latency between order placement and processing.

What a clean external integration looks like
A well-built external WooCommerce order management system does the following:
Registers webhooks on connection (not polling). When you connect your WooCommerce store, it registers the relevant webhook URLs via the REST API automatically. No manual setup, no cron jobs added to your WordPress instance.

Handles webhook signature verification. WooCommerce signs webhook payloads with an HMAC-SHA256 signature using a secret you set at registration. A properly built receiver verifies this signature before processing — rejecting unsigned or tampered payloads.

javascript// Example webhook signature verification
const signature = req.headers['x-wc-webhook-signature'];
const payload = req.rawBody;
const secret = process.env.WC_WEBHOOK_SECRET;

const computed = crypto
.createHmac('sha256', secret)
.update(payload)
.digest('base64');

if (signature !== computed) {
return res.status(401).send('Invalid signature');
}
Pushes stock updates back via REST API with exponential backoff. When inventory changes on any connected channel, the system pushes an update to WooCommerce's product endpoint. A well-built system retries failed updates with exponential backoff rather than dropping them on a 429 or 503 response from your server.

Uses a lightweight WordPress connector. The only footprint on your WordPress installation should be a minimal plugin that registers webhooks and handles authentication. No order processing logic, no database writes beyond what WooCommerce itself handles, no frontend impact.

What to check before connecting any tool
Before you connect a WooCommerce order management tool to a production store, verify four things:
Does it use webhooks or polling? Ask directly. Polling tools will slow your server and introduce sync delays. Webhook-driven tools won't.

Where does processing happen? Plugin-based processing runs on your server. External processing runs on theirs. For anything beyond basic order viewing, external is the right answer.

How does it handle WooCommerce plugin conflicts? Tools that write extensively to the WordPress database or hook into WooCommerce core filters can conflict with Subscriptions, Bundles, WPML, and other extensions. Ask for a compatibility list.

How does it handle failed webhook deliveries? WooCommerce retries failed webhook deliveries five times with increasing delays. Your OMS should also handle duplicate deliveries gracefully (idempotent processing) since the same webhook can fire more than once.

Putting it together
The stores that run WooCommerce cleanly at scale aren't the ones with the most plugins, they're the ones that keep WordPress lean and push complexity to external systems designed for it. WooCommerce's REST API and webhook system make that genuinely possible without custom development.

If you're evaluating tools rather than building your own, this comparison of the best WooCommerce order management systems covers the main options with honest notes on sync architecture, multi-warehouse support, pricing, and where each tool fits. Worth a read before committing to anything.

Nventory is one option that takes the webhook-first, external-processing approach lightweight WooCommerce connector, real-time inventory sync back to your store, and order routing handled entirely on their infrastructure. Free trial if you want to test it against your own store setup.

We cut our dev stack from 22 tools to 14. Here's exactly what survived and why.

Nventory — Tue, 14 Jul 2026 12:15:57 +0000

Six months into building Nventory we had 22 tools running simultaneously.
Not because we planned it that way. Because every problem got a new tool. Every new hire brought their favourite stack. Every integration added another dashboard to check.
Then we did a full audit.
Here's what we cut, what stayed, and the specific reasoning behind every decision. No affiliate links. No sponsored mentions. Just what we actually use building multichannel inventory infrastructure at Nventory.

The full cut list — and why each one went
Jira → Linear
Jira works. It does everything. It also requires maintenance, generates ticket overhead, and produces an interface the team works around rather than with.
Linear replaced it in a week. Not because of features — Linear has fewer. Because adoption happened naturally. The engineering team opens it without being asked.
bash# The Jira workflow reality

Create ticket (5 min — finding the right project, epic, sprint)
Fill in 8 required fields
Estimate story points
Assign to sprint
Move through 6 status columns
Close ticket with comment

The Linear workflow reality

Hit C — create issue
Type the title
Hit Enter
Done Speed of ticket creation is a proxy for whether developers actually create tickets. Linear wins. Confluence → Notion Confluence is where documentation goes to die. Search doesn't work. Pages nest three levels deep. The editor fights you. Notion replaced it for internal wiki, engineering decisions, integration documentation, content calendar, and meeting notes. One tool. One search. Free tier covered everything for the first year. We didn't upgrade until the team exceeded 10 people. Zoom as default → Loom as default Kept Zoom for meetings that genuinely require synchronous back-and-forth. Changed the default. Every "can you walk me through this" became a Loom first. Every code review explanation. Every design feedback session. Meeting load dropped 40%. Not through mandate — through Loom being faster than scheduling. Postman → HTTPie + VS Code REST Client Postman became a cloud-sync subscription product. The complexity it introduced — workspaces, team sync, version conflicts — exceeded the value for our use case. bash# HTTPie — API testing from terminal # Testing our webhook endpoints during development http POST localhost:3000/webhooks/shopify \ X-Shopify-Hmac-Sha256:abc123 \ topic:orders/create \ shop_domain:example.myshopify.com

Clean. Fast. No account required. No cloud sync.

VS Code REST Client handles the rest:
http### Test inventory sync endpoint
POST http://localhost:3000/api/inventory/sync
Content-Type: application/json
Authorization: Bearer {{token}}

{
"sku": "HOODIE-BLK-M",
"quantity": 47,
"channel": "shopify"
}
Two tools replaced. Both free.
Datadog + New Relic → Grafana + Prometheus + Sentry
We ran Datadog and New Relic simultaneously for two months trying to decide between them. The cost was significant. The insight differential was marginal.
Self-hosted Grafana + Prometheus covers metrics and dashboards. Sentry handles error tracking specifically. Total cost: server hosting. Total capability: comparable.
The four metrics that actually matter for our event-driven sync architecture:
javascript// The dashboard we actually look at
const coreMetrics = {
syncLagP99: 'sync_lag_ms p99 < 5000', // event propagation speed
propagationSuccessRate: 'propagation_success / total > 0.99', // channel update reliability
oversellRate: 'oversell_detected_24h === 0', // zero tolerance
dlqDepth: 'dead_letter_queue_depth < 100' // failed propagations
};

// Every other metric is noise until these are green
Amplitude → PostHog
Amplitude is genuinely powerful. It's also genuinely expensive for a team at our stage.
PostHog self-hosted free tier does 90% of what we needed — funnel analysis, session recording, feature flags, and cohort analysis. The 10% gap isn't worth the cost difference at our stage.
Intercom → Crisp
Intercom enterprise pricing at low support volume doesn't make sense. Crisp free tier handles live chat and basic ticketing. When volume grows to justify Intercom's pricing — we'll revisit. Until then, Crisp.
Retool → Next.js internal tools
This one hurt to cut because the promise was compelling. Drag-and-drop internal tooling without writing code.

The reality: our data model for multichannel inventory sync was complex enough that Retool's abstractions became constraints. Every custom behaviour required workarounds that took longer than just writing the component.

We rebuilt the internal tools in Next.js. Took longer upfront. Significantly easier to maintain. No vendor dependency.
Height → Linear + Notion (separate)
Height tried to unify task management and documentation. In theory — better than two tools. In practice the context switching between engineering mode and documentation mode is actually useful. Different tools for different mental states.

The 14 that stayed
Engineering:
├── VS Code (+ GitLens, REST Client, Error Lens, ESLint, Prettier)
├── GitHub (version control + GitHub Actions for CI/CD)
├── Docker + Docker Compose (local dev)
├── Warp (terminal — AI autocomplete for shell commands)
├── TablePlus (database GUI — free tier sufficient)
├── Proxyman (HTTP debugging — invaluable for webhook debugging)
└── Grafana + Prometheus + Sentry (monitoring + error tracking)

Team:
├── Linear (engineering tasks)
├── Notion (everything else)
├── Loom (async communication)
├── Figma (design — free tier)
└── Slack (communication)

AI:
├── GitHub Copilot (autocomplete — unambiguous ROI)
├── Claude (writing, reasoning, code review)
└── Perplexity (research with cited sources)

The tools worth knowing that didn't make the list but deserve mention
Excalidraw — we use this for every architecture diagram before writing code. Hand-drawn aesthetic removes formality and makes it faster to iterate. Used it to design the order routing engine and event propagation architecture.
Warp — the terminal upgrade that actually matters. AI autocomplete for shell commands is genuinely useful day to day. Worth switching from iTerm2.
Raycast - replaces macOS Spotlight. Clipboard history, window management, Linear integration, GitHub integration. The free tier covers everything.
Proxyman - the tool most developers don't know about until they need it. HTTP proxy for macOS that intercepts and inspects all network traffic. Essential for debugging webhook delivery and API integrations.

The underlying principle
Every tool added creates:
javascriptconst toolCost = {
contextSwitching: 'new mental mode to enter and exit',
decisionFragmentation: 'decisions made in tool nobody else checks',
maintenanceOverhead: 'integrations to maintain, credentials to rotate',
onboardingCost: 'new surface area for every hire'
};

function shouldAddTool(tool) {
const habitualAdoption = team.usesWithinTwoWeeks(tool);
const replacesExisting = tool.eliminates.length > 0;
const valueExceedsCost = tool.timeSavedWeekly * team.size >
Object.values(toolCost).reduce(sum) * tool.complexityMultiplier;

// If the team isn't reaching for it habitually — cut it
return habitualAdoption && (replacesExisting || valueExceedsCost);
}
The question before every addition: does the value created exceed the coordination overhead introduced?
For most tools: no. For the 14 that stayed: yes, demonstrably.

What we're building with this stack
Nventory — multichannel inventory and order management. Event-driven sync across 40+ channels in under 5 seconds. AI automation in plain English. Smart order routing. Free forever.
→ nventory.io
→ Shopify Store

The question for dev.to
What's the one tool you cut that you thought you needed?
And what's the hidden tool — the one nobody puts in their blog post — that changed how your team works?

Drop your actual stack below. Not the aspirational one. The one you actually use every day.

Why Inventory Management Is Becoming an Ecommerce Growth Lever

Nventory — Mon, 13 Jul 2026 12:02:30 +0000

For years, ecommerce growth was mostly about acquiring more customers.

Now, I think the bigger challenge is operational efficiency.

Brands are selling across Shopify, marketplaces, social commerce channels, and physical locations. At the same time, AI-powered shopping experiences are increasing expectations around product availability and fulfillment speed. That means inventory accuracy is becoming more important than ever. Recent industry reports highlight unified commerce, real-time inventory visibility, and AI-assisted forecasting as key priorities for retailers in 2026.

The interesting part is that inventory problems rarely show up as "inventory problems."

They show up as:

Stockouts on best-selling products
Excess cash tied up in slow-moving inventory
Manual spreadsheet work
Order fulfillment delays
Conflicting stock numbers across sales channels

Many teams discover that forecasting isn't their biggest issue fragmented data is. When inventory, orders and purchasing workflows live in separate systems, every replenishment decision becomes harder than it should be.

That's one of the reasons we're building Nventory. We keep seeing ecommerce operators spend hours reconciling inventory instead of growing their business.

I'm curious:

What's the biggest inventory challenge you're facing today?

Forecasting demand?
Preventing stockouts?
Managing multiple sales channels?
Replenishment planning?
Something else entirely?

The dev productivity stack we actually use at Nventory and what we cut after wasting months on the wrong tools

Nventory — Fri, 10 Jul 2026 11:48:44 +0000

Every developer productivity post recommends the same tools.
VS Code. GitHub. Slack. Notion. Figma. Linear. Docker. Postman. Datadog.
All good tools. None of that is the interesting part.
The interesting part is what we cut and why cutting things made us significantly more productive than adding them.
Here's the honest breakdown of what we actually use building Nventory — a multichannel inventory and order management platform — what we tried that didn't work, and the specific reasoning behind each decision.

What we cut and why
Jira → Linear
We used Jira for the first four months. It was fine. It did everything we needed it to do. It also required a dedicated person to maintain it, generated overhead on every ticket, and had an interface that the engineering team worked around rather than with.

Linear replaced it in a week. The difference wasn't features — Linear has fewer features than Jira. The difference was that the engineering team actually opened it without being asked. Keyboard-first navigation, instant search, clean sprint views, and no configuration hell.

The only metric that matters for a task management tool is whether the team uses it. Jira: reluctantly. Linear: habitually.

Confluence → Notion
Confluence is where documentation goes to die. Nobody could find anything. Pages nested three levels deep. Search that returned the wrong results. An editor that fought you on every paragraph.
Notion replaced it for internal wiki, engineering decisions, API documentation drafts, content calendar, and meeting notes simultaneously. One tool. One search. Everything findable.
The free tier covers everything a team of under 10 needs. We didn't upgrade for the first year.

Zoom + Slack → Loom + Slack
We kept Slack. We kept Zoom for the meetings that genuinely require real-time back-and-forth.

What changed: the default shifted from "schedule a meeting" to "record a Loom." Every code review explanation, every design feedback session, every "can you walk me through this" became a Loom first, a meeting only if the Loom wasn't enough.

Meeting load dropped by roughly 40%. Not because we mandated async — because Loom made async faster than scheduling.

Postman → HTTPie + built-in VS Code REST client
Postman became a subscription product with a cloud sync model that added complexity we didn't need. For the API testing we actually do day to day — including testing our 40+ channel integrations — HTTPie in the terminal and the VS Code REST Client extension cover it completely.
Free, fast, no account required.

Multiple monitoring tools → Grafana + Prometheus
We went through Datadog, New Relic, and Sentry before landing on a self-hosted Grafana + Prometheus stack with Sentry retained specifically for error tracking. The cost reduction was significant. The visibility improvement was marginal — turns out you need the same four metrics regardless of which tool surfaces them.

The stack that stayed
Engineering core:
IDE: VS Code — with these extensions specifically:
- GitLens (git blame inline, history navigation)
- REST Client (API testing without Postman)
- Error Lens (inline error display)
- ESLint + Prettier (non-negotiable)

Version control: GitHub
CI/CD: GitHub Actions — free tier covers most pipelines
Containers: Docker + Docker Compose for local dev
Database: TablePlus for database GUI (free tier sufficient)
API testing: HTTPie (terminal) + VS Code REST Client
Monitoring: Grafana + Prometheus (self-hosted) + Sentry (error tracking)
Team collaboration:
Task management: Linear (engineering) + Notion (everything else)
Documentation: Notion
Async video: Loom
Design: Figma (free tier)
Communication: Slack
Scheduling: Cal.com (open source Calendly alternative — free)
AI tools we actually use:
Claude: Long-form writing, code review, complex reasoning
ChatGPT: Quick tasks, brainstorming, first drafts
Perplexity: Research with cited sources
GitHub Copilot: Autocomplete — highest ROI per hour of any tool we use
Cursor: AI-native code editor — worth evaluating as VS Code alternative
The AI tooling honest take: GitHub Copilot is the only AI tool where the productivity gain is unambiguous and immediate. The others depend heavily on how you use them. None of them replace thinking — they reduce the cost of expressing and researching.

What we tried that didn't work
Retool — for internal tooling. The drag-and-drop promise didn't survive contact with our actual data model. We ended up building internal tools in Next.js which took longer initially but was easier to maintain.
Amplitude — product analytics. Powerful but overkill at our stage. PostHog on the self-hosted free tier does 90% of what we needed.
Intercom — customer support. Expensive for the volume we had. Replaced with Crisp on the free tier which handles live chat and basic ticketing without the enterprise price tag.
Height — task management. Beautiful product. But the context switching between engineering tasks and documentation is actually useful — having them in separate tools with different mental modes works better for us than a unified tool that tries to do both.

The tools worth knowing that most people don't mention
Excalidraw — free, open source whiteboard for architecture diagrams. We use this constantly for planning order routing logic and sync architecture before writing any code.
Warp — terminal replacement. AI autocomplete for shell commands. The difference between Warp and iTerm2 is the difference between Linear and Jira — not more features, just a tool the team actually enjoys using.
Raycast — macOS launcher that replaces Spotlight. Clipboard history, window management, and direct integrations with Linear, GitHub, and Notion. Free tier is comprehensive.
Proxyman — HTTP debugging proxy for macOS. Better interface than Charles Proxy for intercepting and inspecting API traffic. We use this constantly when debugging webhook delivery for our channel integrations. Free tier covers most debugging use cases.
TablePlus — database GUI. Significantly better interface than pgAdmin or Sequel Pro. Free tier is sufficient for most development work.

The underlying principle
Every tool added to a development stack creates:
→ A new place decisions get made
→ A new context to switch into
→ A new integration to maintain
→ A new onboarding task for every new team member
The compounding cost of tool sprawl is real and it grows with team size.
The question worth asking before adding any tool isn't "does this do something useful?" — almost every tool does something useful. The question is "does the value this creates exceed the coordination overhead it introduces?"
javascript// The tool evaluation function we informally apply
function shouldAddTool(tool) {
const teamActuallyUsesItHabitually = assess(tool);
const replacesExistingToolOrWorkflow = tool.replaces !== null;
const coordinationOverhead = tool.integrationsRequired + tool.onboardingCost;
const valueCreated = tool.timeSavedPerWeek * team.size;

return teamActuallyUsesItHabitually
&& (replacesExistingToolOrWorkflow || valueCreated > coordinationOverhead * 10);
}
If the team isn't reaching for it habitually within two weeks — cut it.

The Nventory stack in one view
We're building multichannel inventory infrastructure — event-driven sync across 40+ channels, AI automation, unified order management, and smart order routing. The stack we use to build it:
Linear — engineering tasks
Notion — everything else
GitHub — version control + CI/CD via Actions
VS Code — primary IDE
Warp — terminal
Grafana — monitoring
Sentry — error tracking
Loom — async communication
Figma — design
Claude — writing and reasoning
Copilot — code autocomplete
Perplexity — research
Fourteen tools. Down from twenty-two when we started. Every cut made us faster.
Worth exploring:
→ nventory - full platform, free forever
→ Shopify App Store - apps.shopify.com/nventory
→ AI Automation Suite - build workflows in plain English
→ Order Routing - intelligent fulfilment routing
→ Integrations - 40+ native channel connections
→ App Store + Play Store - search Nventory

The question for the community
What's the one tool you cut that you thought you needed but didn't?
And what's the one that stayed that surprised you with how much it changed how you work?

Drop your stack below — genuinely curious what the dev.to community is actually running versus what they planned to run.