Multi-million-dollar assemblies, configured to the well. Every downhole tool string is a custom-configured precision assembly — motors, rotary-steerable tools, telemetry, formation-evaluation sensors, tubulars, and support equipment — built to spec for a specific well and a specific set of downhole conditions. The platform manages seven equipment categories across ten sibling tables, each with physical ordering constraints the database honors through every reorder and clone operation. A proven configuration from one well copies to the next — parent record plus all child collections, sequence preserved, keys remapped — because rebuilding a multi-million-dollar tool spec from scratch is a risk nobody should be taking.

Where the next fix is a helicopter ride away. Deepwater drilling runs hundreds of thousands of dollars a day. The right hardware has to reach the right rig on the right day — kitted, shipped, tracked, and confirmed — with waybills, shipping views, and coordinator notifications generated from the same data that configured the tools. When the equipment is miles underwater and the nearest fix is a crew-change flight, the manufacturing system has to be as reliable as the hardware it tracks.

Integrated into the enterprise, not around it. The platform reads SAP sales orders through the client's own enterprise service bus — a versioned SOA contract governed by their integration architecture. The client's security team ran static and dynamic application scans before the platform went to production, and the codebase carries the remediation. When the client hosts production and controls the network, the release discipline has to meet their standard — every deployment is packaged with rollback files so nothing goes out that can't be reversed.

The deliverables the business runs on. Quality forms capture per-sensor performance by category with personnel sign-off, feeding into hole-section scorecards. A single-page performance summary — objectives, operating ranges, actuals, warnings, and an overall grade — is the artifact a manager takes into a post-well review with the operator. Revenue is forecast per service line at day-level granularity, weighted by probability, and rolled into a market view. The platform doesn't just manage the manufacturing process — it produces the documents the business reviews, scores, and invoices from.

A platform that grew with the business. The system started as job management and SAP integration. The client came back for the full tool-request manufacturing subsystem — the single largest expansion in the project's history, 78 tracked work items — because the platform had proven itself as the operational backbone. That is what custom software should be when the builder is still there to grow it with you.

The problem. A company needs a roof, solar array, cell tower, or construction site photographed from the air — specific location, specific week. Owning aircraft nationwide doesn't scale; sourcing a freelancer per job doesn't either, once certification, insurance, equipment, and weather are in play.

What Agilink built. The entire platform — product, build, integrations, and operations: proposal and quoting, mission scheduling, pilot dispatch, media pipeline, QC, delivery, and billing, plus native iOS and Android pilot apps shipped to both app stores. White-label support let other providers run their own customer books on the same platform.

An engineering operation, not a project. The platform grew in deliberate phases — foundation, marketplace operations, native mobile, then enterprise integrations — through 480+ tracked deliveries: roughly 115,000 lines of application code over a 160-table core, every release ticket-tracked.

Matching that understands geography. Pilots are matched on 21 criteria — equipment, thermal and LiDAR capability, FAA Part 107 certification, logged hours, ratings — filtered on real driving distance, resolved and cached per pilot per site. The difference between a pilot who can make the job pay and one who cancels.

Imagery that sorts itself. On upload, the platform reads the GPS coordinates embedded in every photograph and files each image against the nearest asset on the customer's own asset list — automatically, the moment it lands. Nobody hand-sorts a job folder again.

Operations-grade throughout. Weather forecasts pulled every three hours against scheduled sites; one-action dispatch across email, SMS, and push; roughly forty internal job states rolled up to a clean customer view; and a partner API with status webhooks that let enterprise clients file missions straight from their own systems.

Availability isn't a number — it's a calendar. A rented product leaves, stays gone for a variable window, and comes back — so "is this in stock?" depends on the event date, the rental window, and every other customer whose window overlaps. The platform walks every single day of a requested rental window and returns the minimum availability across the range — not the stock on the ship date. Get that wrong and someone's wedding has no flowers. Get it right and the business can confidently sell every unit it actually has free. The naive version of this calculation — check the ship date — looks correct, passes testing, and quietly double-books. The correct version is a recursive day-by-day minimum-across-window check, and it is the hardest single problem in rental commerce.

A rental lifecycle on a retail engine. Off-the-shelf e-commerce assumes goods leave and never come back. This platform handles reserve, pick and pack with printed checklists, ship, event, return, inspect, reconcile, and restock — with three cart modes (rental, sample, and outright purchase) modeled as variant attributes rather than forked product types. A nightly job accrues late-return fees automatically and emails the customer. A second job computes damage and non-return charges from warehouse return scans. The return leg is where rental businesses leak money, and this platform closes the loop.

Twelve integrations running a live operation. Five built from scratch — a warehouse management system, shipping labels with a server-side format conversion for the warehouse print flow, an affiliate program, a daily marketing sync, and a custom fulfillment API for warehouse operations. Two more heavily rebuilt — a carrier integration rewritten from SOAP to REST OAuth2 with custom box-packing logic, and a payments integration carrying Apple Pay, multi-card support, refunds, and delayed rental charges. This was not a website with a checkout button. It was a running business with inventory moving in both directions every day.

Domain logic, not generic commerce. A guided quiz captures wedding style, colors, budget, and the headcount of fourteen distinct wedding-party roles — then computes suggested quantities per product category. Centerpieces from guest count divided by table size. Boutonnières from the sum of grooms, groomsmen, ushers, fathers, and grandfathers. An operations grid shows per-product, per-day availability with encoded cell states distinguishing rentals from samples from purchases, with overbooking flags that surface conflicts before they become someone's problem on a Saturday.

The operator builds the model. Nearly 200 offshore facilities — fixed platforms, caissons, piles — each with its own equipment register, inspection schedules, and compliance records. The equipment module organizes all of it through a four-level hierarchy — facility, asset, component, inspection point — that the operator's own team defines through configuration screens. Asset types, subtypes, component properties, and inspection templates are all administered without a vendor call or a code change. When a new compressor arrives on a platform, the equipment team builds the asset record, attaches the right inspection template, and the scheduling system picks it up. The software adapts to the operation, not the other way around.

Checklist to parts order. A scheduled inspection generates a work order with a per-asset-type checklist — each point completed by the technician, dated, and tracked. A deficiency on any inspection point routes to a corrective work order. A corrective work order routes to a parts requisition with vendor contact, part number, and submission status. The entire chain — from "check the pressure set point" to "replacement parts submitted to vendor" — is one system and one audit trail.

Compliance breadth. The platform extends well beyond equipment — incident reporting through investigation and corrective-action close-out, management-of-change risk assessment, job safety analysis, scored contractor audits, and behavior-based safety observations all share the same architectural pattern: configurable taxonomies, position-based permissions, and a shadow audit trail beneath every record. When the regulator asks for documentation, one system produces it.

Stewardship, not projects. New modules, reconfigured workflows, and new integrations ship as the operation evolves — without a re-implementation, a platform migration, or a break in compliance history. The operator's institutional knowledge and every record ever entered are still intact, still queryable, and still audit-ready. That is what a long-term relationship with your software vendor actually looks like.

Two native apps, nine modules, both app stores. The carrier needed its entire operational picture in the hands of the people moving the freight — on iOS and Android, natively, shipped to both public app stores. This was not a proof of concept — it delivered with nine operational modules, eight authorization roles, and a map-based asset search with configurable radius. Terminal directory, tractor and trailer search, load board, five-tab order detail, settlement statements with downloadable PDFs, and self-service registration — all at feature parity across both platforms. When the business needs mobile and can't afford to build it twice, this is what it looks like to build it once per platform and get it right.

Eight roles, one app, different views. An owner-operator opens the app and sees exactly their settlement statements — gross, deductions, reimbursements, net — and nobody else's. A third-party carrier sees carrier pay where an internal employee sees total charges on the same screen, physically recomposed per role rather than merely hidden. The authorization model carries eight distinct roles, four server-controlled capability flags, and per-user data scoping down to the individual terminal, payee, customer, and driver level. One app handed to dispatchers, agents, owner-operators, carriers, drivers, and shippers — six audiences, one codebase per platform, zero trust in a role dropdown.

Find the asset, call the terminal, move the load. Tractor search runs on a live map with a user-set radius — the same filtered result set renders as both a list and a map from a single shared search-state model. Tap a tractor for detail and trailer status, then tap to call — and before the dialler opens, the app silently logs which tractor was called, by whom, through which terminal, so the carrier can measure whether the tool is actually moving freight. The load board, order detail, and settlement modules are the ones that make this an operations product rather than a lookup app — and every one of them works identically on both platforms.

Built to hand over. The client's own developer held the final commit on both platforms, co-developing alongside the Agilink team during the last phase. The product went on shipping new public releases without us — sixteen versions in all. A mobile app that survives the team that built it is uncommon. One that keeps shipping afterward is a handover that worked — and that is what the client is buying when they ask whether we'll still be useful after the build.

The client calls it a competitive advantage. The carrier's own public website lists this product on their technology page as a differentiator — in their own words, unprompted. A public app-store review called it fast and easy to navigate. The app was eventually succeeded — not because it failed, but because the technology matured and the business wanted a consolidation. That is the lifecycle custom software should have.

Forms driven by data, not code. Each clinical indication — men's health, women's health, weight management, dermatology, hair restoration — has its own form definition driving which compounded preparations appear, at which strengths, in which dispense units, with which directions, quantities, and refill options. Adding a new indication or adjusting an existing form is a data change, not a release. The pharmacy tuned forms continuously through the service desk after launch — which is exactly what the architecture was designed to allow.

Signed, rendered, transmitted. A completed order renders through a server-side Razor-to-PDF pipeline into a document that reproduces the pharmacy's own paper form — with the prescriber's stored digital signature composed in and fonts embedded so the output matches the original. The PDF transmits via a HIPAA-oriented fax service using encrypted per-request authentication. The receiving end of the workflow did not have to change at all, which is why the system could go live quickly against a pharmacy still running a paper-and-fax operation.

Built for regulated work. Production runs on Aptible — a platform built for healthcare workloads, with encryption at rest, encrypted backups, infrastructure audit logging, and a Business Associate Agreement. Containerized with Docker and deployed from GitHub Actions with CI/CD. Role-based access control separates who may draft an order from who may submit one — a real clinical-governance distinction, modeled in the permission tree. Bulk onboarding from spreadsheets with row-level validation and reject export handles the rollout to dozens of clinics without making it a quarter-long project.

A company's entire blending mathematics, rescued from a DOS program. The application is not a fresh implementation of gas blending — it is a traceable, deliberate port of the client's original QuickBasic program. The live source code cites the original by filename and line number in its own comments. The original all-caps BASIC variable names survive in the C#. The port was faithful enough to carry forward a genuine quirk of the original, which the client's own veteran operator recognized from memory and confirmed rather than reporting as a new bug. For any business owner running a critical calculation on aging software, this is the proof that the answer to "can you move this without losing what it knows?" is yes.

Precision that catches the fourth significant figure. A compressibility factor printed as 0.9846 instead of 0.9831 — a discrepancy against an outside reference laboratory's certificate — was caught, root-caused to a missing summation factor in a published industry standard, and fixed the same day. The printed certificate now carries the same summation column the lab report carries, with a visible flag when a factor is absent. Percentages carry six decimal places, densities five, requested grams three, actual weighed grams four. And because rounding each row independently could make a column total 99.999999%, the balance-gas row is computed as the remainder so the printed column always sums to exactly 100%. This is what domain fluency looks like from the inside.

Fill pressure from physics, not a lookup table. Before a cylinder is filled, the application computes the maximum safe fill pressure by ensuring no single component's partial pressure exceeds its own vapour pressure — the constraint that stops a component condensing back to liquid inside the cylinder and destroying the blend. It sorts components by vapour pressure, walks them accumulating mole fraction, and takes the binding constraint. Competitors' software takes a fill pressure as an input. This one derives it.

Zero IT involvement. On first run the application detects there is no database server, silently extracts and installs SQL Server Express from a bundled installer, configures it, starts the service, enables the network protocol, opens the firewall, sets the authentication mode, and attaches the database — reporting progress on its own splash screen. A build pipeline refuses to compile unless the version number agrees across every place it is written, then reads the compiled binary's raw bytes to verify the version badge that will actually render. For a manufacturer with no IT department, this is a system that installs itself and proves its own releases.

Seven log types for a 24-hour surveillance operation. A casino surveillance department is a round-the-clock operation where everything that crosses the desk has to be written down — calls from other departments, exceptions seen on camera, incidents that become formal reports, cameras that stop working, and what one shift needs the next shift to know. The written record is not administrative overhead. It is the department's compliance product, and it is what gets produced when a regulator, an investigator, or a court asks what happened. Seven log types — daily calls, pass-on notes, incidents, exception reports, camera outages, adjustments, and regulatory notifications — each with its own fields, its own numbering, and its own printed output, all aligned closely with what federal minimum internal control standards require of a tribal casino's surveillance department.

Every edit shadowed, every delete recorded. Nine database triggers shadow-copy every insert, update, and delete across the two core event tables and the acknowledgement ledger into dedicated audit tables, stamped with the action, the user, and the timestamp. An operator can correct a record — but the original version, the change, and who made it are permanently on file. This is the difference between a logbook application and a compliance system — the record has to be defensible under examination, not just searchable.

Shift hand-over with a signed acknowledgement chain. The outgoing shift writes pass-on notes. Each incoming operator sees only the notes they have not yet acknowledged, confirms each one, and that confirmation is appended to an auditable ledger. The printed pass-on report shows, for any note from any date, the full roster of exactly who signed off and when. Any operation that runs in shifts — offshore, hospital, plant, security — has this problem. A system that can print, for any hand-over note, who confirmed they read it and when, is answering a question every regulated shift operation has.

Volume that proves production use. One log type alone generates 5,895 records per month. When the grids slowed under accumulated data, the client came back and funded a log-archival subsystem — archive and un-archive by date range or hand-picked selection, with a live-versus-archived toggle, an audited activity history, and asynchronous execution added after the synchronous version timed out on real volume. A system does not accrue a log-archiving problem without serious production use. That dependency chain is production evidence that does not depend on anything anyone said.

The filing, not a report about it. The system doesn't generate a summary someone then retypes into a regulator's portal. It writes the agency's own submission file — cloning the federal template database, populating it column for column against the agency's field constraints, validating every record before generating, and aborting with a diagnostic email rather than producing a broken filing. State air-permit applications assemble the same way — cover sheet, table of contents, certification, emissions history, equipment tables, and a completeness checklist — paginated and merged from the state's own section templates. The line between compliance software that helps and compliance software that delivers is whether the output is the filing itself. This one is.

When the rules change, the data changes. Roughly 1,150 emission-calculation formulas live as rows in the database, not as compiled code. Each formula carries a target field and an ordinal position; they evaluate in dependency order, each result feeding the next through a hand-written expression evaluator built specifically so regulatory arithmetic never has to live in a release cycle. Scientific notation is expanded to forty decimal places before evaluation — because emission factors are written as 1.2E-05, and truncation in a figure destined for a federal filing is not acceptable. The same definitions drive both server-side calculation and live browser recalculation, so what the user sees is what the filing will contain.

Twenty-four source types, four federal permits, one system. Amine units, compressor seals, diesel engines, flares, glycol dehydrators, storage tanks, pneumatic devices — each with its own data-entry screens, calculation methodology, inventory reporting, and named engineering correlations. Offshore emissions inventories for BOEM. Title V and minor-source operating-permit applications for the state. Discharge monitoring reports under four federal water permits, with exceedance detection that alerts at the keystroke, not at month-end close. Most compliance tools cover one regulatory medium. This one covers air, water, and the permitting that ties them together.

Built for the service relationship. The operator's staff enters their own monthly data, scoped to their company and their facilities. Then the consultancy's engineers review and certify — two independent locks, encoded in the schema. A separate flare and vent quality-control surface catches missing days, not just wrong numbers, because in flare reporting a gap is the failure mode. A facility-transfer wizard moves an asset's entire compliance history between operators when ownership changes — because in this industry, assets get sold and the compliance record has to follow. The software encodes a service contract, not just a data model.

Software that talks to metal. This is not a form over a database — it is an own-built Modbus TCP master. One class per function code, byte ordering and CRC-16 computed by hand, raw socket on port 502. Twelve heating zones per controller. It writes to the hardware: full ramp-and-soak profiles per zone, run state, segment jumps, duty cycle, setpoints, offsets, the controller's clock, and calibration state. A safety interlock detects a stuck contactor or a sustained heater malfunction and sends a trip command to a breaker relay coil — the software does not just observe a runaway heater, it de-energizes it. For any manufacturing or industrial-services prospect, this is the difference between shop-floor monitoring software and shop-floor control software.

The certificate proves the instrument was calibrated. Every treatment certificate bakes in each participating controller's calibration date and certificate number. Calibration itself is a three-point state machine hosted in the controller, with Type K thermocouple millivolt mathematics and cold-junction compensation computed against NIST reference tables shipped with the application. The traceability chain runs from the individual weld through the heating zone, through the controller, to that controller's dated calibration certificate and its in-tolerance verification samples. That chain is what a quality auditor actually asks for — and it is properly implemented rather than gestured at.

Multi-day runs that cannot be allowed to fail. Treatments run for days. Per-tick session checkpoints with corruption detection and field-preserving merge-on-save. A four-stage startup restore chain that promotes a crash-time backup only when it is genuinely newer, not still locked, and deserializes cleanly. The controllers themselves are the recorder of record — they log samples onboard — so a treatment survives a PC reboot and the application rejoins in progress. A wireless serial bridge that holds ghost TCP sessions after a crash required a specific socket-error detection and a sixty-second backoff — because retrying hard resets the bridge's idle timeout and guarantees permanent failure. Nobody invents these fixes. They are proof of years on real shop floors.

The exact document the business already runs on. The client's quality forms existed as manually completed Excel workbooks. Those forms now generate from the recorded process data, cell by cell, into the client's own committed template workbooks, preserving the workbook's live formulas. The treatment certificate exports as the client's own numbered form with a per-zone timestamped temperature worksheet at an operator-chosen interval. No retraining, no parallel system — the output is the document the business already knew how to use.

The cycle runs the business. Every week, a scheduled engine selects eligible subscribers, generates their orders, respects per-customer auto-select preferences, sequences dietary-restriction customers first so they get first call on constrained stock, charges the cards, and logs every decision. The cycle is re-runnable — if a production night goes wrong, operations can safely regenerate orders for that menu without side effects. Order generation is decoupled from payment collection, so a failed card never destroys an order. This is the piece no off-the-shelf e-commerce platform does, and it is the reason the system exists.

Geography and the calendar, built in. Delivery runs inside zip-code zones with geocoded boundaries. Pickup locations are a first-class entity. The mapping from "delivery day" to "the day the cycle runs" is a configuration row carrying a day offset — so "the Thursday box is generated on Monday" is changed by operations, not by a developer. Courier bulk handoff, fourteen operational reports — menu worksheet, routes, delivery-day breakdown, inventory, sales — and a comms engine driving fifty-one transactional email templates round out the operations layer.

Payments that keep up. A Stripe integration on PaymentIntents — saved cards, refunds, 3D Secure detection with a clean customer message and an internal alert — extended with Apple Pay and Google Pay digital wallets. The payment code handles the checkout path and the subscription-collection path separately, and failure alerting is wrapped so a mail outage can never affect a payment result. A platform whose payment stack takes digital wallets is a platform that is being maintained, not just kept alive.

A rescue that stuck. Agilink inherited a stalled build from a previous vendor, rebuilt the platform, put it into production, and still ships to it. That is the answer to two questions at once: can they take over someone else's work — and will they be there when you need them again.

Two companies, one codebase, no rewrite. The firm acquired a second business with different billing rules — day periods versus fractional hours, different expense types, different mileage precision, different rules for zero-hour entries and overtime. Rather than fork the system or buy a second one, the platform added a login-time company selector that sets the connection, the membership provider, the file paths, the reports, and the behavior flags. Every stored procedure call in the system inherited multi-tenancy from a single change in the data-access layer. Two databases, two rule sets, one codebase — the exact shape of the "we've acquired a business and now we have two systems" problem, solved without a rewrite.

Compliance that blocks the work — and hands you the form. Before a broker can save a timesheet, the system checks whether they hold the documents that project requires. If something is missing, it does not just refuse — it renders the required form as a PDF, presents it inline, captures a cryptographically signed signature against a certificate, and files the signed document as a first-class record. Separately, a weekly sweep emails brokers seven days before their professional license or insurance policy expires, with accounting copied. Anyone who has managed a licensed contract workforce understands what this prevents — someone working, and being billed, on a lapsed credential.

The money path, end to end. Client invoicing, broker pay, payroll with holiday and overtime and PTO accrual — all generated from the same approved time records. A layered rate card resolves from client-and-role down to project-level overrides and per-broker exceptions. Effective-dated rate changes apply forward without touching invoices already sent. A state-based tax allocation maps every billable day to the jurisdiction where the work was performed. The platform carries the full financial lifecycle — from a field agent logging a day's work to the invoice, the pay cheque, and the tax record.

A small back office running a large field workforce. Sixty-five reports across two operating companies cover invoicing detail, broker summaries by state, payroll, compliance expiry, and exception reports that surface timesheets that look wrong. A queue-backed notification system routes time approvals, credential reminders, and password resets through Azure Communication Services with per-tenant sending identities. The approval chain — broker verifies, project manager approves or rejects with a reason that emails the broker, administrator closes the period — enforces the workflow that keeps the billing clean. This is the platform a ten-person office uses to run a distributed field operation without losing control of the money.

The design is the quote. An engineer designs a frac treatment — zones, stages, fluid systems, pump rates, sand concentrations that ramp across each stage — and the platform computes slurry volumes, proppant mass, clean rates, and stage durations from first principles. Those computed volumes and masses become priced line items automatically, against a regional rate card, with cost, discount, and margin visible per row. A live traffic light paints the profit cell red on a negative margin as the estimator works. The engineering document and the commercial document are the same object — which eliminates the spreadsheet-to-spreadsheet disagreement every services business with a technical front end lives with.

Offline, and peer-to-peer. The field application runs a full local SQL Server Express instance on each laptop. Data moves bidirectionally between the well site and the office over Microsoft Sync Framework — and also directly between field laptops via live network discovery, so two crews on the same pad can reconcile whether or not either can reach the office. A separate schema-sync scope propagates database changes to already-deployed machines before the data scope runs, so a structural change at the office reaches every field laptop without anyone visiting it. For any business with field crews in places with no signal, this is the architecture that actually works.

Thirty-eight fields, and they are the right thirty-eight. The treatment record captures instantaneous shut-in pressure at five, ten, and fifteen minutes, fracture gradient, breakdown pressure and the rate and volume at breakdown, ball-seat pressures, min/max/average pressure and rate, designed volume against actual, and pumps lost — split into terminal and non-terminal failures. On that same record: invoice number, PO number, AFE number, bill-to, and currency. The engineering result and the billable event are one row. The customer's representative signs on a signature pad at the well site, the field ticket prints on site, and the signed record syncs back to the office.

Proposals that become jobs. Approving a proposal deep-copies the entire design tree — wellbore, zones, stages, fluid chemistry, pricing — into a live job across roughly ten tables, re-associating children by business key. The quote and the live work stay cleanly separate, and a revised proposal never disturbs an active job. Getting a hierarchical clone right in one pass, in the database, at the moment of commercial commitment, is the kind of work that is invisible when correct and expensive when not.

Every unit, every day, every dollar. The company's fleet — portable buildings, water-pressure systems, sewage plants, support equipment — rents to oil and gas operators by elapsed time, not by sale. The platform tracks every individually identified unit through its lifecycle: on the yard, delivered to a job site, returned, re-rented, sold. Each one barcoded for physical yard reconciliation. The two questions the business lives by — what's available right now, and what will this month bill — are answered from the same transaction history, because they have to be.

Oilfield billing, not generic invoicing. A single job's charges split across multiple AFE numbers at configurable percentages, with offshore lease-block tracking. The monthly invoice run generates in bulk across all open jobs for a period, with preview, discounting, and a period lock so a closed month cannot be re-billed. Generated invoices export to QuickBooks and import into the general ledger — not a CSV someone retypes, a working accounting handoff. This is the difference between an equipment-rental app and one built for a business whose customers run their own capital-authorization audit trails.

Proposals that become jobs. Approving a proposal doesn't set a flag — it deep-copies the entire commercial structure into a live job: item groups, AFE splits, tax treatment, and seed transactions, all cloned and the source archived. Quoting and operating stay cleanly separate, and a proposal can be revised without disturbing live work. Getting a structural clone right in one pass — nested groups, percentage splits, transaction history — is the kind of work that is invisible when correct and catastrophic when not.

Revenue that forecasts itself. The period forecast projects forward from every unit currently out on a job, at its contracted rate, under its AFE split and tax treatment, period by period. The platform doesn't just track equipment — it produces the monthly billing and the forward revenue view the business runs on.