Why I Built an AI Decision Support Copilot for Executives

 For years, I’ve been building software — from blockchain exchanges to AI agents.

But one problem kept repeating itself in every company I worked with:

Executives don’t lack data.
They lack clarity.

Every business today stores massive amounts of information in PostgreSQL, MySQL, MS SQL, analytics tools, CRMs, ERPs — you name it. Yet when a CEO asks:

• “Did revenue really increase because of pricing strategy?”

• “Which region is underperforming this quarter?”

• “Are our operational costs rising faster than revenue?”

• “What actually drove Q4 growth?”

The answer usually takes days.

That’s not because the data isn’t there.
It’s because getting the right data requires technical effort.

The Real Problem With Business Intelligence

Traditional BI dashboards show charts.
But executives don’t think in charts.

They think in questions.

Most business intelligence tools require:

• Pre-built dashboards

• Static metrics

• Data team involvement

• Manual query building

What’s missing is structured reasoning.

An executive question isn’t just a SQL query.
It’s a process:

1. Understand the intent

2. Plan the analysis

3. Fetch the right data

4. Validate assumptions

5. Deliver a clear conclusion

That’s why I started building an AI decision support system — not just another chatbot.

From AI Chat to AI Decision Support

Most AI tools generate text.
That’s not enough for real business.

What businesses need is an AI business intelligence tool that:

• Connects securely to company databases

• Executes read-only structured queries

• Plans before answering

• Combines multiple datasets

• Produces visual insights and conclusions

In short: an AI copilot for executives.

That is exactly what I’m building with 👉 https://www.bizcopilot.app

BizCopilot is designed as an AI decision support copilot that helps executives analyze company data using natural language — while keeping database access secure inside the organization’s infrastructure.

It doesn’t guess.
It plans, retrieves, verifies, and concludes.

Why This Matters Now

The speed of decision-making is becoming a competitive advantage.

Companies that can analyze data instantly:

• Adjust pricing faster

• Detect operational inefficiencies earlier

• Identify profitable segments sooner

• Respond to market changes immediately

AI for business executives is no longer a futuristic idea.
It’s becoming operational infrastructure.

And in my view, the future of business intelligence is not dashboards.

It’s structured AI reasoning directly connected to real company data.

If you're interested in how AI can transform decision-making inside your organization, you can explore more about this approach at https://www.bizcopilot.app.

We are just getting started.

I Was Saved by AI

This morning, around 7:00 AM, I tried to start my car.

Nothing happened.

The doors wouldn’t unlock using the remote. I had to open the car manually with the physical key. When I turned the ignition, there was no response at all. No sound. No lights.

I checked the car battery first.
The indicator was green, which usually means it’s still healthy.

Just to be sure, I tried jump-starting the car using another battery.
Still nothing.

At that point, I felt confident about one thing.

I’ve had a very similar case before.
Back then, the problem turned out to be the alternator—and I had it replaced.

So naturally, my mind went there again.

I started calculating the cost.
Around 200 USD for the alternator, not including labor.
Plus the time, the workshop visit, and possibly calling a tow truck.

Before doing anything else, I did something different.

I talked to ChatGPT.

The suggestion was simple:
“Try replacing the remote battery.”

Honestly, I didn’t believe it.

Based on my previous experience, the alternator explanation felt much more reasonable. The AI’s answer felt too small for what looked like a big problem.

Still, I decided to try.
Not because I was convinced—but because it was cheap and harmless.

I waited until the shop opened and bought a new remote battery.

When I got home, I replaced it immediately.

The car started right away.

Wow.

At that moment, I realized AI had saved me from several things:

• An unnecessary trip to the workshop

• Unneeded repair costs

• Calling a tow truck

• And possibly being “convinced” by a dishonest mechanic that the alternator was broken

This small experience made me reflect.

There is no undo button for AI.

I consider myself a scientific person. Even without data, we often begin with a hypothesis. But this reminded me that past experience can easily turn into bias.

AI is already changing jobs, workflows, and entire industries. Whether we like it or not, this shift cannot be reversed.

If we don’t adapt, we will fall behind.

What happened with my car happens in business all the time—expensive decisions made from assumptions instead of validated data.

That’s why I’m building BizCopilot.

A business assistant that helps people analyze their own company data.
Not to replace decision-makers, but to challenge assumptions and support better decisions.

AI is not an autopilot.
It’s a copilot.

And sometimes, it saves you with something as simple as a battery.

Perbandingan Biaya & Performa AI Agent: Gemini Flash 2.5, GPT-4o-Mini, dan LLaMA Phi-3 Mini

Dalam pengembangan AI Agent untuk aplikasi production, dua hal utama yang selalu menjadi pertimbangan adalah performa dan biaya operasional. Untuk itu, saya melakukan pengujian pada tiga model berbeda—Gemini Flash 2.5, GPT-4o-mini, dan LLaMA Phi-3 Mini yang dijalankan di server baremetal—untuk melihat model mana yang paling efisien dan realistis dipakai dalam skenario dunia nyata.

Tulisan ini merangkum hasil pengujian tersebut, mencakup kecepatan respon, akurasi, kebutuhan hardware, dan estimasi biaya dari masing-masing model. AI Agent dikembangkan untuk bisa membaca data-data spesifik secara realtime. Algoritma yang digunakan untuk semua model dalam AI Agent adalah sama sehingga kita dapat perbandingan kecerdasan, ketepatan dan kecepatan model.

---

📌 Model yang Diuji

1. Gemini Flash 2.5 (Google)

Dirancang untuk kecepatan dan efisiensi biaya. Dari seluruh pengujian, model ini memberikan hasil paling cepat dengan struktur jawaban yang bersih dan rapi.

2. GPT-4o-mini (OpenAI)

Model kecil namun sangat stabil dan konsisten. Menawarkan kualitas reasoning yang cukup baik tanpa biaya setinggi model besar.

3. LLaMA Phi-3 Mini (Server Baremetal)

Model ini dijalankan di server pribadi dengan spesifikasi:

• 20 core CPU

• 8 GB RAM

Hasilnya cukup mengejutkan—meskipun ukurannya kecil, performanya justru sangat lambat, dengan karakteristik:

• CPU selalu terpakai 100% selama inference

• RAM hampir tidak terpakai

• Tidak adanya GPU menjadi bottleneck besar

• Waktu response sangat lama

Temuan penting: LLM modern tetap membutuhkan GPU; CPU saja tidak cukup untuk pengalaman penggunaan yang layak.

---

⚡ Performa Model

Gemini Flash 2.5

• Respons paling cepat di antara semua model.

• Output rapi, stabil, dan mudah diproses.

• Ideal untuk workload singkat maupun intensif.

GPT-4o-mini

• Jawaban akurat dan sangat konsisten.

• Lebih lambat dari Flash 2.5, tetapi kecerdasan reasoning lebih baik.

• Cocok untuk aplikasi yang membutuhkan keseimbangan antara kualitas dan biaya.

LLaMA Phi-3 Mini

• Performa paling lambat.

• Akurasi rendah dibanding model cloud.

• Keuntungan utama: dapat berjalan sepenuhnya offline.

---

💰 Estimasi Biaya Menggunakan API

1. Gemini Flash 2.5

Perkiraan biaya API:

• Input: $0.10 per 1 juta token

• Output: $0.30 per 1 juta token

Simulasi (1.000 pengguna × 20 query/hari × 400 token):

• Total token/hari: 8.000.000

• Biaya per hari: ± $3.20

• Biaya per bulan: ± $96 (≈ Rp 1.536.000)

Kesimpulan: Murah, cepat, dan stabil → pilihan terbaik untuk produksi skala kecil hingga menengah.

---

2. GPT-4o-mini

Perkiraan biaya API:

• Input: $0.15 per 1 juta token

• Output: $0.60 per 1 juta token

Simulasi yang sama (8 juta token/hari):

• Biaya harian: ± $6

• Biaya bulanan: ± $180 (≈ Rp 2.880.000)

Kesimpulan: Lebih mahal dari Flash 2.5, tetapi memiliki kemampuan reasoning yang lebih baik.

---

💻 Estimasi Biaya Menjalankan LLaMA di Server Baremetal

Menjalankan LLaMA sendiri memang gratis dari sisi API, tetapi memiliki biaya infrastruktur yang tidak kecil.

1. Biaya Server

Opsi yang mungkin digunakan:

• Server fisik: tergantung spesifikasi

• VPS setara 16–20 vCPU: Rp 600.000 – Rp 1.200.000/bulan

2. Biaya Listrik (server 20 core)

• Konsumsi saat inference: ±150W

• Total pemakaian: 150W × 24 jam × 30 hari = 108 kWh/bulan

• Tarif PLN: Rp 1.700/kWh

• Total biaya: ± Rp 183.600/bulan

3. Kesimpulan LLaMA Lokal

• Privasi tinggi dan tanpa biaya API.

• Namun lambat tanpa GPU, memerlukan listrik cukup besar, serta butuh maintenance.

• Tidak disarankan untuk aplikasi publik atau skala besar.

---

🧾 Ringkasan Perbandingan

Model	Kecepatan	Biaya Bulanan	Cocok Untuk
Gemini Flash 2.5	⭐⭐⭐⭐⭐	± Rp 1.5 juta	Production skala kecil-menengah
GPT-4o-mini	⭐⭐⭐⭐	± Rp 2.8 juta	Production menengah-atas
LLaMA Phi-3 Mini	⭐⭐	± Rp 200 ribu + listrik/maintenance	Riset, offline, privasi tinggi

---

📝 Kesimpulan Utama

• Gemini Flash 2.5 → paling cepat dan paling hemat; sangat direkomendasikan.

• GPT-4o-mini → lebih mahal tetapi reasoning lebih kuat.

• LLaMA Phi-3 Mini → cocok untuk penggunaan privat/offline, tetapi tidak efisien tanpa GPU.

Dengan memahami biaya dan performa masing-masing model, kita bisa menentukan model mana yang paling sesuai untuk kebutuhan AI Agent—baik untuk riset maupun skala produksi yang lebih luas.

Tutorial: Backup and Restore iptables Configuration

This step-by-step guide will walk you through backing up your current iptables configuration and restoring it when needed.

---

Prerequisites

• Administrative privileges (root access) on the system.
• Basic understanding of iptables commands.

---

1. Backup iptables Configuration

Step 1: Check the Current iptables Rules

Before creating a backup, view the current rules to ensure they are correct:

sudo iptables -L -n -v

Step 2: Save the Current iptables Configuration

Use the iptables-save command to create a backup file of your current configuration:

sudo iptables-save > /etc/iptables.backup

• This command saves the current rules to /etc/iptables.backup.
• You can replace /etc/iptables.backup with a file path of your choice (e.g., /home/user/iptables.lastgood).

Step 3: Verify the Backup

View the contents of the backup file to ensure the rules were saved correctly:

cat /etc/iptables.backup

---

2. Restore iptables Configuration

Step 1: Restore from the Backup File

To restore the iptables rules from your backup file, use iptables-restore:

sudo iptables-restore < /etc/iptables.backup

• This command applies the rules saved in the backup file.

Step 2: Verify the Restored Rules

After restoring, confirm that the rules are active:

sudo iptables -L -n -v

---

3. Automate iptables Rules Persistence

Option 1: Use a Startup Script

Add the restore command to a script that runs at startup:

1. Edit the rc.local file:

   sudo nano /etc/rc.local
   

2. Add the following line before exit 0:

   /sbin/iptables-restore < /etc/iptables.backup
   

3. Save and exit the file. Ensure the script is executable:

   sudo chmod +x /etc/rc.local
   

Option 2: Create a Systemd Service

1. Create a systemd service file:

   sudo nano /etc/systemd/system/iptables-restore.service
   

2. Add the following content:

   [Unit]
   Description=Restore iptables rules
   After=network.target
   
   [Service]
   Type=oneshot
   ExecStart=/sbin/iptables-restore < /etc/iptables.backup
   RemainAfterExit=yes
   
   [Install]
   WantedBy=multi-user.target
   

3. Save and enable the service:

   sudo systemctl enable iptables-restore.service
   

---

4. Best Practices

1. Create Regular Backups If you make changes to your iptables rules, back them up again:

   sudo iptables-save > /etc/iptables.newbackup
   

2. Test New Rules Before applying significant changes, test them carefully to avoid locking yourself out.

3. Store Backups Securely Keep your backup files in a secure location and name them descriptively (e.g., iptables.goodbackup or iptables.date.backup).

---

By following these steps, you can ensure that your iptables configuration is always backed up and easily restorable.

Backup Semua Database PostgreSQL dalam Container

Langkah 1: Identifikasi Container PostgreSQL

Gunakan perintah docker ps untuk menemukan container PostgreSQL:

docker ps

Catat CONTAINER ID atau NAMES dari container PostgreSQL.

Langkah 2: Backup Semua Database

Gunakan docker exec untuk menjalankan pg_dumpall di dalam container:

docker exec -t <CONTAINER_ID_OR_NAME> pg_dumpall -U <username> > backup_all_databases_$(date +%Y%m%d_%H%M%S).sql

Di sini, <CONTAINER_ID_OR_NAME> adalah ID atau nama container PostgreSQL Anda, dan <username> adalah nama pengguna untuk PostgreSQL.

Langkah 3: Menyimpan Backup di Lokasi yang Aman

Simpan backup di lokasi di luar container untuk keamanan, contoh:

docker exec -t <CONTAINER_ID_OR_NAME> pg_dumpall -U <username> > /path/ke/backup/di/host/backup_all_databases_$(date +%Y%m%d_%H%M%S).sql

/path/ke/backup/di/host adalah lokasi di host di mana Anda ingin menyimpan file backup.

Langkah 4: Verifikasi Backup

Setelah backup dibuat, Anda bisa menguji restore-nya dengan membuat container baru atau menggunakan container yang ada untuk restore semua database:

cat backup_all_databases_20241209_080000.sql | docker exec -i <CONTAINER_ID_OR_NAME> psql -U <username> postgres

postgres di sini adalah database default tempat psql akan menjalankan query. Ini akan menginisiasi restore semua database dari file backup.

Catatan: Pastikan pengguna yang Anda gunakan (<username>) memiliki izin yang cukup untuk mengakses semua database yang akan di-backup. Juga, file backup bisa sangat besar jika Anda memiliki banyak database atau data dalam jumlah besar.

Cara Mengetahui Besar Database PostgreSQL Tanpa Mendownloadnya

Berikut adalah langkah-langkah untuk mengetahui ukuran semua database di instance PostgreSQL yang berjalan di dalam kontainer Docker:

1. Mengakses Kontainer Docker:

   Gunakan perintah `docker exec` untuk mengakses shell dari kontainer Docker yang menjalankan PostgreSQL. Gantikan `[container_name_or_id]` dengan nama atau ID kontainer yang sebenarnya:

   ```

   docker exec -it [container_name_or_id] bash

   ```

2. Menghubungkan ke PostgreSQL:

   Di dalam kontainer Docker, hubungkan ke server PostgreSQL menggunakan perintah `psql`. Kita bisa masuk sebaga user `postgres` atau sebagai user lain. Tetapi dalam contoh ini kita menggunakan user postgres:

   ```

   psql -U postgres

   ```

3. Melihat Besar Semua Database:

   Setelah berada dalam `psql`, eksekusi query SQL berikut ini untuk mendapatkan ukuran setiap database di instance PostgreSQL:

   ```

   SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;

   ```

   Perintah ini akan mencantumkan semua database beserta ukurannya dalam format yang mudah dibaca (seperti MB atau GB).

4. Opsional - Total Ukuran Semua Database:

   Jika Anda tertarik untuk mengetahui total ukuran gabungan semua database, Anda dapat menggunakan perintah ini:

   ```

   SELECT pg_size_pretty(SUM(pg_database_size(datname))) FROM pg_database;

   ```

   Ini akan memberikan Kita satu ukuran kumulatif untuk semua database.

Setelah menjalankan perintah-perintah ini, Kita akan memahami ukuran masing-masing database dan ukuran total yang ditempati oleh semua database di instance PostgreSQL Kita di dalam Docker.

Menggunakan Artillery untuk Testing

Dalam era digital saat ini, meningkatkan performa aplikasi web dan memastikan aplikasi dapat menangani beban yang besar adalah hal yang penting. Salah satu alat yang dapat membantu kita memastikan bahwa aplikasi kita tahan banting adalah dengan melakukan pengujian beban. Salah satu alat untuk melakukan pengujian beban adalah Artillery.

Apa itu Artillery?

Artillery adalah alat pengujian beban yang modern, powerful, dan fleksibel. Dengan Artillery, pengembang dan tester dapat mengujian aplikasi mereka di berbagai skenario untuk memastikan bahwa aplikasi mampu menangani beban yang diharapkan. Artillery mendukung pengujian terhadap berbagai protokol seperti HTTP, WebSocket, dan lainnya.

Mengapa Menggunakan Artillery?

1. Sederhana namun Kuat: Artillery memiliki konfigurasi yang sederhana dalam format YAML atau JSON, namun memiliki fitur yang kuat untuk menguji berbagai aspek aplikasi.
2. Skalabilitas: Anda dapat menjalankan pengujian dari satu mesin atau mendistribusikannya ke banyak mesin untuk mensimulasikan ribuan pengguna.
3. Statistik yang Detail: Setelah pengujian, Artillery memberikan laporan rinci mengenai latensi, throughput, jumlah kesalahan, dan metrik lainnya.
4. Ekstensibilitas: Artillery dapat diextend dengan plugin untuk menambahkan fungsionalitas atau untuk mendukung protokol lain.

Bagaimana Cara Menggunakan Artillery?

1. Instalasi

   Untuk memulai, Anda perlu menginstal Artillery. Dengan asumsi Anda telah menginstal Node.js, Anda dapat menginstal Artillery dengan npm:

   npm install -g artillery

2. Membuat Skenario Pengujian

   Buat file konfigurasi dalam format YAML atau JSON. Sebagai contoh:

   
   config:
     target: 'http://your-api-endpoint.com'
     phases:
       - duration: 60
         arrivalRate: 5
   scenarios:
     - flow:
         - get:
             url: '/endpoint'
         - post:
             url: '/post-endpoint'
             json:
               key1: 'value1'
               key2: 'value2'
           

   Dalam konfigurasi di atas, Artillery akan mengirimkan 5 permintaan per detik ke http://your-api-endpoint.com/endpoint selama 60 detik.

3. Jalankan Pengujian

   Setelah Anda memiliki file konfigurasi, Anda dapat menjalankan pengujian dengan perintah:

   artillery run namafilekonfigurasi.yml

4. Menganalisis Hasil

   Setelah pengujian selesai, Artillery akan menampilkan ringkasan statistik. Anda juga dapat menyimpan hasil pengujian ke file atau database untuk analisis lebih lanjut.

Kesimpulan

Artillery adalah alat pengujian beban yang sederhana namun kuat yang dapat membantu pengembang memastikan aplikasi mereka berfungsi dengan baik di bawah beban. Dengan Artillery, Anda dapat dengan mudah mensimulasikan lalu lintas ke aplikasi Anda dan mendapatkan insight mengenai performa dan titik-titik kelemahan yang mungkin ada.