How I work: FDE-style delivery
FDE (Forward Deployed Engineer) names the role: embedded on site, turning complex operations into product you can ship—not hand-off requirements and wait.
Draw the path with the people doing the work; the proposal forms while understanding; first call is where it is stuck, not a feature list.
Four methods
Path before features
Split screens only after you can draw who starts, approves, executes, and reconciles. Plant admin, OTD configurator, and the sales-procurement system all started here.
Master data apart from documents
Keep master data (assets, orgs, customers, suppliers) separate from work orders and sales orders—one sheet should not be both archive and process.
Draw boundaries on purpose
Saying what you will not build matters as much as what you will: plant admin does not take over units; the AI platform does not own model quality; benefits do not rewrite payments.
Configurable, not hard-coded
Pack nodes, I/O, and permissions into adjustable process—not a hard-coded UI per scenario.
Services
Custom product development
From business mapping to go-live, one person closes the loop. The sales-procurement system is the proof: real clients, real operations.
Product consulting & solution design
Turn complex operations into a shippable product plan—the same method as plant admin and OTD configurator: path first, features second.
Zero-to-one product coaching
For teams with clear process but no system: fold offline workflows in spreadsheets and chat into configurable product.
AI tools & skill customization
Turn repeated decision flows into an AI skill. The product-selection skill is the example: cross-signal validation and explainable conclusions.
Good fit
- Export SMBs: business in email, sheets, and chat—needs a system.
- Clear process, no system: still human-driven, needs productization.
- Need product capability without hiring a team: full methodology by project.
Engagement flow
Talk → proposal (path + boundaries) → quote → milestone delivery
Generic layer semantics
Shared language for admin systems (no stack picks):
- Access: admin portal with role-based menus and permissions—not one UI for every role.
- Application: modules by domain (master data, process, rules, documents)—bound the domains before splitting services.
- Data: master data separate from operational documents, plus audit/logs for traceability.
- Integration: connect to existing ERP / MES / production or commerce systems—do not rewrite shop-floor control or core ledgers.
Sizing independent deployment
Order-of-magnitude method—no preset cores/RAM:
- Stateless apps: size instances by admin-seat count and peak concurrency; scale out. Ask “who is on at once” before asking for a machine SKU.
- Database: document volume and whether reporting contends with writes decide read replicas or a separate reporting store.
- Files and logs: attachments, exports, and audit trails should not live only in the OLTP database.
- A separately deployed mid-size admin module is usually app instances + database + needed middleware. Spine vs edge modules differ by a tier. Core/RAM are an engineering load-test call; product states availability, permissions, audit, and order-of-magnitude volume.
Aligning with engineering
Domains before services; product states bounds and NFRs, engineering owns stack and sizing—verified on plant admin, OTD, and AI platform work.