Field 00 / Statement
Fig 0.1 / Data flow, one engagement

Hong Kong / 22.2819 N 114.1583 E
Fig 0.1 in flight 000 / held for review 000

AlpineDrop Ventures Limited. Software engineering, registered in Hong Kong.

We build production softwareon the systems you already run.Built to run after we leave.

An agent that answers from your own Zendesk archive, and says so when it cannot. A pipeline that keeps your Shopify orders in your own Postgres through every schema change. The back end of a marketplace you operate. Built in your accounts, handed over working, and run by us only for as long as you want. You own all of it.

Write to info@alpinedropventures.com

Describe the system and what it should do. The reply comes from the engineer who would build it.

Not an investor. Not a holding company. An engineering firm that builds for a fee.

Legal name

AlpineDrop Ventures Limited

Registered in

Hong Kong

Business

Custom software development for business clients

Contact

info@alpinedropventures.com

01 The firm

A small engineering firm, registered in Hong Kong. Paid to build, not to invest.

AlpineDrop Ventures Limited is a Hong Kong registered software engineering firm that designs, builds and maintains custom software for business clients: AI agents over the client's own data, marketplace software for the company that operates the marketplace, data pipelines from the client's own business systems, and workflow automation.

The word Ventures is part of the name. It is not a description of the business. We do not invest in companies, hold shares in them, take equity in place of a fee, or handle money on anyone's behalf. Companies hire us to build software. We build it, and we invoice them for it.

Who hires us: companies, not consumers. Operators of online marketplaces. Retailers on Shopify or a platform like it. Software companies with data they have never been able to query. Service businesses with a support queue, whose records live in Zendesk, Salesforce, a call recording archive, or a database nobody wrote down. Engagements are contracted with the client company, invoiced in the currency named in the scope document, and delivered remotely, wherever the client is based.

Small on purpose. The person who scopes the work writes the code and is on call when it is live. There is no account manager between you and the engineer. That limits how much we take on at once, and it means we decline work we could not do well.

Ref 1.1 / Reference readoutRendered text, selectable

Legal name: AlpineDrop Ventures Limited
Form: Limited company, registered in Hong Kong. An operating technology services firm, not an investment vehicle of any kind.
Activity: Custom software development and IT consultancy
Customers: Business clients only. No consumer sales, no marketplace of our own, no handling of client funds.
Where: Delivered remotely into the client's own accounts, wherever the client is based
Registered office: Office 3906, 39th Floor, The Center, 99 Queen's Road Central, Central, Hong Kong
Full company information block
Contact: info@alpinedropventures.com

02 What we build

Four things we build, each specific enough to put on an invoice.

Each one names the systems it runs against and the part of the work that is actually hard. Each ends the same way: a system you run, in accounts you own.

01AgentsRetrieve / cite / decline

Agents that answer from your own records, and say so when they cannot.

The model is the easy part. The records are the hard part. Ten years of Zendesk tickets where the useful answer is in the third reply of a merged thread. Call recordings where the account number is said twice, differently. A product catalogue with four SKUs for one product. Internal documentation that was last true before the reorganisation. We build the retrieval layer over that: chunking that respects where a document actually ends, an embedding index and a keyword index because neither is enough alone, metadata filters so a question about the current contract is not answered from the one it replaced. Every answer cites the passage it came from. When retrieval finds nothing good, the agent says so, in words, and hands off to a person.

A confident answer from the wrong document is the failure that reaches a customer with your name on it. It is the one we design against first, and the one the evaluation set is built to catch. If your records cannot support what you want to ask of them, we say so at the scoping stage, before anyone has paid for the attempt.

Runs against: Zendesk, Intercom and Freshdesk exports. Call recordings and their transcripts. Confluence, Notion, SharePoint, Google Drive. Product catalogues. Internal PDFs and spreadsheets.
You get: The agent as a service in your cloud account. The ingestion pipeline that keeps it current. An evaluation set built from your real questions, with the wrong answers marked. A review screen that shows what it said, what it cited, and where it declined.

Fig 2.1 / Retrieve, answer or decline

02MarketplaceOperator / builder

The back end of a marketplace. You operate it. We build it.

You run the marketplace. You hold the licence, the merchant account and the contract with the payment provider. We are the engineers you hire to build what sits behind it. Catalogue and search, including the part where two sellers list the same product under different titles. Seller onboarding and identity checks, wired to the verification provider you chose. Order state, so a cancellation after dispatch does not leave a payout half made. Payout calculation, which your own licensed provider settles from your accounts. And the operations tooling nobody demos: the refund queue, the dispute screen, the seller suspension button, and the reconciliation report that says what your ledger thinks the provider owes and what the provider says it paid. Every marketplace needs that report.

Money moves through your accounts at your licensed provider. We do not operate marketplaces, and we do not hold, receive or transmit funds for anyone. We write the code that instructs your provider, and the code that checks the instruction was carried out.

Your side: Licence. Merchant account. Provider contract. Seller and customer relationships. The money.
Our side: Catalogue. Search. Onboarding. Order state. Payout logic. Operations tooling. Reconciliation. The code.

Fig 2.2 / The operator boundary

03PipelinesCursor / backfill / drift

Pipelines out of the systems you already pay for, still running after handover.

Your Zendesk, your Salesforce, your Shopify, your call recordings, your internal APIs. Under your credentials, with your written authorisation, through the interfaces those vendors document, with the narrowest permissions that do the job. Getting the data out once is a script. Keeping it flowing is the work. Shopify meters you with a leaky bucket. Salesforce gives you a daily quota and an error for everything past it. Zendesk answers with a 429 and a Retry-After header that has to be honoured. Pagination that changes shape halfway through a backfill. A field that was a string in March and an object in April, with nothing in the changelog. Deleted records that never appear in an incremental pull unless you ask for them by name.

We build the pipeline that handles all of that, lands the data in a warehouse you own with a schema you can read, backfills history without tripping the limits, and alerts a person when the shape of the data drifts.

Runs against: Zendesk, Salesforce, HubSpot, Shopify, Klaviyo, Stripe exports, call recording platforms, and the internal APIs your own team wrote.
You get: The pipeline code. The schema, documented. The backfill runbook. The drift monitor. Not a dashboard over a black box.

Fig 2.3 / Checkpoint, cursor, backfill

04AutomationLog / replay / off switch

Loops that run without a person in the middle, with the failure path designed first.

Every automated workflow is a promise that a person no longer needs to look. Lead arrives, gets enriched, gets routed, gets a first reply. Ticket arrives, gets classified, gets the right macro or the right human. Stock drops below threshold, purchase order drafts itself. Email sequence fires on a real event instead of a timer. None of this is hard to build. It is hard to build so that it fails well. What happens when the enrichment provider is down for an hour. What happens when the ticket is actually three tickets in one message. What happens when the stock count is wrong because a return was booked twice.

We write those paths first, then the happy path. Every automated action is logged with what it saw and why it decided. Every one can be replayed. Every one has an off switch a non-engineer can reach.

Wires together: Klaviyo, HubSpot, Zendesk, Shopify, Slack, Google Workspace, and whatever your own database is called.
You get: The workflows as code, in your repository. The audit log. The replay tool. The off switch.

Fig 2.4 / Failure paths designed first

03 How the work runs

Scoped in writing. Running in the first month. Yours at the end.

This is the section other firms fill with photographs. We would rather tell you how the work is bought, built and handed over, and how the money and the obligations move. Six parts, in the order they happen.

Part 1

Before anything is built

You email us a description of the system and what it should do. We reply with questions, mostly about where the data lives and who owns the accounts. If it is work we should do, we write a scope document: what gets built, what it connects to, what done looks like, what it costs, in which currency, and when it is invoiced. You sign it or you do not. There is no discovery retainer and no proposal deck.

Fees are invoiced by AlpineDrop Ventures Limited to the client company, on the schedule set out in that document. Ongoing operation, where you want it, is agreed and priced separately, in writing, before it starts. When the scope changes, the document changes first, in writing, and the work follows.

Part 2

The first month

Week one is access and reading: your repositories, your schemas, your API keys placed in your secrets manager rather than pasted into a chat. For an agent we write the evaluation set before we write the agent. For a pipeline we agree the record counts before we move a record, so both sides know what finished looks like. By the end of week two something runs against real data in a staging environment you can log into.

Weeks three and four are the ugly middle: the edge cases the data reveals, the rate limit hit at three in the morning, the field nobody knew was nullable. Month one ends with a system in production for a bounded slice of the problem, and a written note on what the next slice is. If what we found means the original scope was wrong, we say so then, not at the end.

Part 3

What you own at the end

Everything. The repository, under your organisation from the first commit. The infrastructure, in your cloud account, on your billing. The credentials, in your vault, revocable by you. The documentation, in the repository, not in our heads. The prompts, the evaluation sets, the runbooks. Nothing is licensed back to you, nothing runs through an account we control, and nothing needs our permission to change. When the engagement ends, nothing has to be transferred, because nothing was ever ours.

Part 4

After handover

Handover is a scheduled event, not a slow fade: a walkthrough of the running system, the runbook for the failures we designed for, and the alerting pointed at your people. Then two options, both written into the scope document. You run it, and we stay available for questions and changes on terms agreed in the scope document. Or we run it: we hold the pager, patch dependencies, watch the drift alerts and ship changes, priced per system and agreed in writing.

Either way the code stays yours and the access stays yours to revoke. Moving from one option to the other is a change of who is on call, not a migration.

Part 5

If it stops early

You keep everything built to that point, in a state you can run or hand to someone else. Invoicing at that point covers the work done, not the work planned.

Part 6

What we do not take on

Work in which we would hold, move or manage money for anyone.
Work in which the data is not yours to give us.
Work that needs a large team quickly. We are a small firm and do not pretend otherwise.
A price before anyone has seen the data. We give a scoped price after the first look, not before.

We would rather decline early than deliver something we cannot stand behind.

Ref 3.1

A system you cannot run without us is not finished. We do not deliver those.

04 Production

Production is not the same as deployed.

A demo runs once, on the author's laptop, against a clean sample. Production runs every day against the data as it actually is. The gap between those two is where all our time goes, and we can list what closes it.

A system is in production when

P-01It runs in your environment, under your credentials, in accounts you pay for.
P-02Every job can be run twice without doing the work twice. A retry never double-charges, double-sends or double-inserts.
P-03An alert reaches a named person when it stops. Not a dashboard someone might look at.
P-04You can show, from the logs, what it did last Tuesday and why. One trace per request, end to end, in your own logging.
P-05For anything with a model in it, a fixed set of questions with known answers is re-run before every change, and the results are kept.
P-06A day of missed data is recovered from the source, not lost.
P-07An engineer who was not there when it was written can redeploy it from the repository.

Until every line is true, it is a demo, however good it looks.

Built beside the old thing, not instead of it.

The systems we build do not arrive into an empty room. They land beside a Shopify store with custom apps, a Salesforce instance nobody has cleaned since the migration, a Zendesk with more macros than agents, a spreadsheet that is secretly the source of truth, and an application nobody wants to touch that still takes orders. We build beside all of it. We read through the interfaces each vendor documents, under your credentials, within the vendor's terms. We write back only where the scope says so, and only behind a flag that turns the write off. We mirror the legacy data into a schema you can query before touching anything a customer sees. We replace the old thing last, if at all, and only after the new one has run beside it long enough to prove they agree. Where a vendor's interface is incomplete, we work with what it exposes and write down what it does not, so you know the gap is the vendor's and not ours.

How we choose the parts

Boring by default: Postgres unless there is a reason. A queue with a dead-letter path. Containers on the cloud you already pay for. A model called through its vendor's API rather than hosted by us. Nothing you would need to hire a specialist to keep alive.
Secrets in a vault: Never in code. Never in a chat message. Never in a .env committed by accident. The pipeline checks for all three.
Small blast radius: One workflow failing does not stop the others.
Reversible: Every deployment has a rollback, and the rollback has been run on purpose before it is needed.
Tested where it hurts: Fixtures built from real, anonymised payloads, including the malformed ones. A schema-drift test that fails the build when a vendor renames a field.

05 Query

Trace a record through a delivered system.

The diagram is the shape of one engagement: your sources on the left, your store and services in the middle, your people on the right, and the side channels for everything that goes wrong. Type a source, or press one, and the path it takes lights up. Every answer the query line gives is drawn from this page, and nothing you type leaves it.

Fig 5.1 / Reference architecture, one engagementSolid, data. Dashed, exceptions. Amber, the traced path.

Query line. Reads from this page only. Type help, or press a command.

trace zendesk the path a ticket takes, lit up above

trace shopify the path an order takes

trace drift what happens when a field changes shape

company the reference readout, as text

services the four things we build

engagement the six parts of an engagement

own what you own at the end

production when a system counts as in production

contact the one address

Commands / press to run

Fig 5.1 / Reference architecture, one engagement. The same diagram is described in words under 04 Production.

06 Contact

One address. Read by a person.

Email info@alpinedropventures.com. Say what system you have, what it should do, and where the data lives. That is enough for a first reply. There is no form and no booking link, because neither tells us anything an email does not. The person who reads it is the person who would scope the work. We answer every enquiry, including the ones we decline.

info@alpinedropventures.com

AlpineDrop Ventures Limited. Registered in Hong Kong. Legal name, registered office and email are in the company information block below, as text you can copy.