Forward Deployed Engineer 101: Building Dashboards and Data Products (Quick Visualizations with Superset, Tableau, or Custom React)

Building Dashboards and Data Products (Quick Visualizations with Superset, Tableau, or Custom React)

Field-Ready Study Guide: Building Dashboards & Data Products (Quick Visualizations with Superset, Tableau, or Custom React)

What This Is

As a Forward Deployed Engineer (FDE), you’ll often need to build, deploy, and iterate on dashboards and data products under tight deadlines—whether for a military ops center, a disaster response team, or an enterprise customer with strict security constraints. These tools turn raw data into actionable insights, but the real challenge isn’t just making a pretty chart—it’s deploying it securely, ensuring it works in constrained environments, and adapting it to real-world chaos (e.g., air-gapped networks, last-minute customer pivots, or data that’s messy, incomplete, or classified).

Field Example:
You’re deployed to a classified military base where analysts need real-time visibility into drone footage metadata. The customer insists on a Tableau dashboard, but their network is air-gapped, their data is stored in a proprietary format, and their IT team won’t allow Docker. You have 48 hours to deliver something usable. You: 1. Reverse-engineer their data schema (no docs exist).
2. Write a Python script to clean and transform the data into a SQLite DB (since they won’t let you install PostgreSQL).
3. Build a lightweight React dashboard (since Tableau Desktop won’t run without internet for activation).
4. Burn it to a DVD (their only approved transfer method) and train the team in person.

This guide covers how to do this efficiently, securely, and repeatably—whether you’re using Superset, Tableau, or a custom React app.

Key Terms & Concepts

• Air-Gapped Deployment: Deploying software in a network with no internet access. Requires offline dependencies, manual approvals, and physical media (USB/DVD). Common in defense/intel.
• Ask vs. Infer: The customer says they need a "real-time dashboard" (the ask), but the data shows they only check it once a day at 0800 (the infer). Build for the latter.
• Superset / Tableau / Metabase: Open-source (Superset) vs. proprietary (Tableau) vs. lightweight (Metabase) BI tools. Superset is the FDE default—it’s free, Docker-friendly, and works offline.
• React + D3.js / Plotly: For custom dashboards when BI tools are too rigid. Use Create React App (CRA) or Next.js for quick setups.
• Data Pipeline (ETL/ELT): The Extract-Transform-Load process. In the field, you’ll often skip fancy tools and use Python (Pandas) + SQLite for speed.
• Embedded Analytics: Dashboards that live inside another app (e.g., a React component in a customer’s portal). Requires auth integration (OAuth, JWT).
• ATO (Authorization to Operate): A security approval required for any software in government/enterprise. Plan for this early—it can take months.
• ACO (Authority to Connect): Permission to plug into a customer’s network. Often requires firewall rules, VPN configs, or physical access.
• Hotfix vs. Patch: A hotfix is a quick, temporary fix (e.g., a Python script to clean bad data). A patch is a permanent, tested update (e.g., a new Docker image).
• Bastion Host: A jump server used to access restricted networks. You’ll SSH into this first, then pivot to the target machine.
• Data Provenance: Tracking where data came from, how it was transformed, and who touched it. Critical for audits and trust in high-stakes environments.
• Offline-First Design: Assume no internet, slow networks, or intermittent connectivity. Cache data, pre-compute aggregations, and minimize API calls.

Step-by-Step / Field Process

1. Discovery: Understand the Real Problem (Not the Ask)

Goal: Avoid building the wrong thing.
Actions:
- Ask the 5 Whys (e.g., "Why do you need a dashboard?" → "To track drone footage." → "Why?" → "To find anomalies." → "Why?" → "Because we’re missing threats.").
- Map the data flow:
- Where does the data live? (SQL DB? CSV files? A proprietary system?) - Who owns it? (IT? A contractor? A classified team?) - What’s the refresh rate? (Real-time? Daily? Ad-hoc?) - Check constraints:
- Network: Air-gapped? Firewall rules? VPN required? - Security: ATO/ACO needed? Can you use Docker? Are there approved software lists? - User skills: Will they use Tableau, or do they need a click-and-forget React app?

Field Command:

# Quick data profiling (if you have SSH access)
ssh user@bastion -L 5432:db.internal:5432  # Port-forward to DB
python -c "import pandas as pd; df = pd.read_sql('SELECT * FROM logs LIMIT 1000', 'postgresql://user:pass@localhost:5432/db'); print(df.describe())"

2. Choose the Right Tool (Speed vs. Flexibility)

Goal: Pick the fastest, most deployable solution.
Options:
| Tool | Best For | Field Notes | |---------------|-----------------------------------|-----------------------------------------------------------------------------| | Superset | Quick, offline, Docker-friendly | Default for FDEs. Works air-gapped, supports SQL, Python, and REST APIs. | | Tableau | Enterprise, polished dashboards | Avoid if air-gapped (requires internet for activation). Heavy license costs. | | Metabase | Simple, open-source, lightweight | Good for non-technical users, but limited customization. | | React + D3| Custom, embedded, high-performance| Use when BI tools are too rigid. Requires more dev time but scales. |

Decision Tree:
- Need it in 24 hours? → Superset (Docker + SQLite).
- Customer insists on Tableau? → Push back (or use Tableau Public + export to PDF).
- Data is messy/real-time? → React + Plotly (more control).
- Air-gapped? → Superset or React (Tableau won’t work).

3. Build the MVP (Minimum Viable Product)

Goal: Get something usable in front of the customer ASAP.
Actions:
- For Superset:
bash # Quick Superset setup (Docker, air-gapped) docker run -d -p 8080:8088 --name superset apache/superset docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email [email protected] --password admin docker exec -it superset superset db upgrade docker exec -it superset superset init - Connect to data: Use SQLite (for air-gapped) or PostgreSQL (if allowed).
- Build a dashboard: Start with 1-2 key charts (e.g., time-series, bar chart).
- Export as JSON (for backup) or PDF (for offline sharing).

• For React + D3:
  bash # Quick React setup (offline) npx create-react-app dashboard --template typescript cd dashboard npm install plotly.js react-plotly.js
• Fetch data: Use local JSON/CSV (for air-gapped) or REST API (if network allows).
• Pre-compute aggregations (e.g., daily averages) to reduce client-side load.

• Deploy: Build static files (npm run build) and burn to DVD/USB.

• For Tableau (if forced):

• Use Tableau Public (free, but not for classified data).
• Export to PDF and email/print (avoid Tableau Server in air-gapped environments).

4. Deploy Securely (Assume the Worst)

Goal: Get the dashboard running in the customer’s environment without breaking security.
Actions:
- For air-gapped:
- Package dependencies offline:
bash
# For Python (Superset)
pip download -d ./deps pandas sqlalchemy # Download wheels
# For React
npm install --production # Then zip node_modules - Transfer via approved media (DVD, USB, sneakernet).
- Test in a staging environment that mirrors the customer’s setup (same OS, firewall rules, etc.).

• For network-restricted:
• Use a bastion host to access internal resources.
• Port-forward to test locally:
  bash
ssh -L 8080:localhost:8080 user@bastion # Forward Superset port

• Check firewall rules (e.g., iptables -L or netsh advfirewall show allprofiles).

• For embedded dashboards (React):

• Use JWT/OAuth for auth (if the customer has an existing system).
• Static hosting: Serve from Nginx or Apache (no dynamic backend needed).

5. Train & Handoff (Avoid "It’s Broken" Calls)

Goal: Ensure the customer can use and maintain the dashboard.
Actions:
- Write a 1-pager (no fluff): - How to access (URL, credentials).
- How to refresh data (e.g., "Run python update_data.py").
- Who to call (your contact info + backup).
- Record a 2-minute Loom video (screen recording) showing: - How to filter data.
- How to export results.
- Set up a "war room" Slack channel for the first 48 hours (expect questions).

6. Iterate (Expect Chaos)

Goal: Adapt to new requirements, data changes, or security issues.
Actions:
- Monitor usage:
- Superset: Check the query logs (SELECT * FROM logs WHERE action = 'query').
- React: Add Google Analytics (if allowed) or log to a file.
- Plan for hotfixes:
- Bad data? Write a Python script to clean it.
- Broken chart? Roll back to a known-good version (use Git tags).
- Document everything (even if it’s just a Google Doc). Future you (or the next FDE) will thank you.

Common Mistakes

Mistake 1: Assuming the Customer’s Data is Clean

• Correction: Always profile the data first (e.g., df.describe(), df.isnull().sum()). In the field, 50% of your time will be cleaning data.
• Why? A dashboard is useless if the data is wrong.

Mistake 2: Building for Your Lab, Not the Customer’s Environment

• Correction: Test in a staging environment that mirrors the customer’s setup (same OS, firewall rules, network latency).
• Why? What works on your MacBook will break behind their firewall.

Mistake 3: Over-Engineering the MVP

• Correction: Start with the simplest possible solution (e.g., Superset + SQLite). Add complexity only if needed.
• Why? The customer will change their mind in 48 hours. Don’t waste time on features they won’t use.

Mistake 4: Ignoring Security Until the End

• Correction: Talk to the customer’s security team on Day 1. Ask:
• What’s the ATO process?
• Are there approved software lists?
• Can you use Docker? Python? React?
• Why? If you build a React dashboard but the customer bans Node.js, you’re screwed.

Mistake 5: Not Planning for Offline Use

• Correction: Assume no internet. Cache data, pre-compute aggregations, and minimize API calls.
• Why? In the field, networks fail. Your dashboard should still work.

FDE Interview / War Story Insights

1. "The Customer Demands a Feature That Violates Scope"

How to Respond:
- Acknowledge: "I understand this is important to you." - Clarify: "Can you help me understand the mission impact? What problem does this solve?" - Propose: "Here’s a lightweight alternative that fits within our constraints. Can we test it first?" - Escalate: If they insist, document the request and get written approval (CYA).

Why? Customers will change scope mid-mission. Your job is to protect the timeline while keeping them happy.

2. "The Dashboard Works in Dev but Fails in Prod"

How to Debug:
1. Reproduce the issue in a staging environment that mirrors prod.
2. Check logs (docker logs superset, journalctl -u nginx).
3. Test connectivity (telnet db.internal 5432, curl http://api.internal).
4. Isolate the problem (is it the data, the network, or the code?).
5. Write a hotfix (e.g., a Python script to clean bad data).

Why? In the field, dev != prod. Always test in the exact customer environment.

3. "We Need This in 24 Hours, and the Data is Classified"

How to Execute:
- Use Superset + SQLite (no internet, no complex setup).
- Burn the dashboard to a DVD (approved transfer method).
- Train the team in person (no remote access).
- Document everything (even if it’s just a text file on the DVD).

Why? Classified environments don’t allow remote access. You’ll physically deploy the solution.

Quick Check Questions

1. You’re deploying Superset to an air-gapped network. The customer won’t let you use Docker. What’s your first step?

Answer: Download the Superset source code and dependencies offline (e.g., pip download -d ./deps superset), then transfer via USB/DVD and install manually.
Why? Air-gapped means no internet, so you can’t pull Docker images or PyPI packages.

2. The customer’s data is in a proprietary format (e.g., a binary file from a military sensor). How do you build a dashboard?

Answer: Write a Python script to parse the binary file (using struct or a library like construct), convert it to CSV/SQLite, then load it into Superset/React.
Why? You can’t assume standard formats in the field. Reverse-engineer the data first.

3. The customer’s security team says your React dashboard violates their policy because it uses node_modules. What do you do?

Answer: Build the React app into static files (npm run build), then serve them via Nginx/Apache (no Node.js runtime needed).
Why? Static files don’t require a backend, so they’re easier to approve.

Last-Minute Cram Sheet

1. Superset default port: 8088 (Docker: 8080:8088).
2. React build command: npm run build → outputs to ./build.
3. SQLite for air-gapped: sqlite3 data.db → .mode csv → .import data.csv table.
4. Port-forwarding: ssh -L 5432:db.internal:5432 user@bastion.
5. Check firewall rules (Linux): iptables -L or ufw status.
6. Check firewall rules (Windows): netsh advfirewall show allprofiles.
7. Quick data profiling: python -c "import pandas as pd; print(pd.read_csv('data.csv').describe())".
8. ⚠️ Always test in the customer’s environment – what works in your lab will break behind their firewall.
9. ⚠️ Assume no internet – cache data, pre-compute aggregations, and minimize API calls.
10. ATO = Authorization to Operate (security approval). ACO = Authority to Connect (network access). Plan for both early.