GEO – Global Energy Optimizer

Portfolio, Ventures & What I Build

Product/systems design that turns AI tech into business results

I'm Gil, an AI Product Design Engineer. I take complex workflows and turn them into AI-native systems, from discovery through shipped product.

My north star is the complete practitioner: the idea that the best AI-native products are shaped by one mind that can hold design, engineering, and AI logic simultaneously, not handed off through layers of interpretation.

When the same person who defines the workflow also builds the prototype and wires the AI, translation loss disappears. Teams move faster and the gap between what we designed and what shipped closes.

What I Bring

Enterprise Systems

Enterprise End-to-End Systems Builder

I've designed complex product ecosystems at enterprise scale — multi-product platforms, multi-role workflows, and long-running transformation initiatives as a solo designer. Systems thinking, not just screen design.

AI Product Engineering

AI-Native Product Design Engineer

I design and prototype AI-native product systems — RAG pipelines, agentic workflows, human-in-the-loop interfaces, structured outputs, and context-aware products. AI product work grounded in real systems, not demos.

Education & Evangelism

Technical Educator & Evangelist

I help people understand, adopt, and build with new technologies — through demos, workshops, tutorials, and product systems thinking. Teaching as adoption; adoption as product design.

A consistent practice across technology cycles

Tech Speaker Microsoft · 5,000+ developers

Co-founder 8th Light · Digital transformation

Startups + Enterprise Engine Yard · ThoughtWorks · Dev tools

Founder Skowak · Design engineering · Teaching

Enterprise Focus SunPower · Digital transformation · Ecosystems

AI Eng Focus Craftal · CareDash · Multi Agent Systems

Now Contextus · Craftal v.2 · AI-native systems

How I Work

I don’t start with AI. I start with how work actually happens.

The method works in cycles. Each one scoped small enough to prove value fast, wide enough to compound across the whole system.

Each cycle makes the next one faster, safer, and more valuable. Real workflows before AI use cases. No baseline, no proof. No proof, no scale.

01 — 03

Understand

Discover
Model
Baseline

Know before you build

04 — 06

Intervene

Design
Adapt & Script
Measure

Build small, prove value

07 — 08

Promote

Promote
Orchestrate

Make it durable and connected

09 — 10

Scale

Govern
Reuse & Expand

Govern and compound

Where most AI projects break down

Most AI failures aren't technical. They're structural: siloed teams, AI built without real workflows, ideas that can't survive contact with production. The method closes those gaps.

Design, engineering, and AI in separate rooms

Work lands in three different hands. Every handoff is a translation, and translation is where ideas lose fidelity.

One practitioner across all three layers

I lead design, write code, and wire the AI as one strategic partner across all three disciplines. No handoffs, no interpretation layers, no gap between what was designed and what shipped.

AI built without a workflow to plug into

Teams rush to launch LLM features with minimal ROI. Without mapping real workflows or solving real problems, the result is unused chatbots and shallow automation.

Bridge between LLMs and real work

I map how work actually happens first, then wire the AI stack into those real decisions. The result is automation that runs, not a chatbot no one uses.

Technical Toolkit

The full stack, from workflow model to deployed AI system.

My stack spans the full system: AI engineering (OpenAI & Anthropic APIs, LangChain, LangGraph, DSPy, RAG pipelines, vector stores, structured outputs, agent orchestration), frontend and prototyping (React, Angular, Vue, TypeScript, API-connected interfaces), backend and tooling (Python, FastAPI, Rails, PostgreSQL/pgvector, Docker), and product and design (systems modeling, workflow mapping, information architecture, interaction design, design engineering).

As a product generalist, I choose the right tool for each layer (design, front end, data, or model) so ideas travel from workflow model to shipped system without unnecessary handoffs.

Getting personal

Things I do when I'm not building

Still-life sketching, coastal hiking, PC teardowns, and slow travel through cities with good architecture.

I draw to stay sharp. I travel to stay curious. I take things apart to stay honest about how they work.

Back

GEO – Global Energy Optimizer

A geospatial solar planning platform for defining sites, simulating layouts, optimizing system parameters, and generating project proposals.

Skills applied:

Visual Design Interaction Design Prototype Dev Research Information Arch

Utility-scale solar planning required teams to evaluate large sites, compare system assumptions, estimate production, and translate early feasibility into proposal-ready project data.

I designed GEO as a geospatial planning tool that connected satellite maps, site blocks, exclusions, simulations, layout parameters, BOM estimates, and proposal outputs in one workflow.

The Problem

Utility-scale planning needed speed without losing technical judgment.

Large solar projects start with uncertainty. Teams need to understand land area, site boundaries, terrain, product configuration, capacity, yield, constraints, customer context, and financial viability before a project can move forward.

That work often happens across disconnected tools: mapping software, spreadsheets, engineering assumptions, separate proposal documents, and manual analysis. Each handoff adds friction and makes it harder to compare scenarios quickly.

The challenge was not just showing a map. The product needed to help teams turn a potential solar site into a structured planning model that could support simulation, design refinement, and proposal work.

diagram geo 01 — Utility-scale planning depended on disconnected tools, assumptions, and handoffs.

Without a unified planning environment, early-stage decisions were slower, harder to compare, and more dependent on manual translation between design, engineering, and business teams.

Solution

Turning the map into the operating surface.

I designed GEO around the idea that the satellite map should not be a passive backdrop. It should become the primary working surface for solar planning.

The login and opening experience established the product as a global planning environment, with projects distributed across geographies and energy markets.

sunpower geo 01 — GEO opened with a global energy planning context.

Once inside a project, the map became the center of the workflow. Teams could see solar sites, project lists, geographic context, site boundaries, planning blocks, and exclusion zones in one place.

sunpower geo 02 — The map canvas helped teams define solar sites and planning zones.

This was the important design decision: GEO had to feel like a planning cockpit, not a form-based engineering tool. The user needed to stay oriented spatially while adjusting assumptions and moving toward analysis.

Creating projects without breaking map context

Project creation had to feel lightweight because teams might evaluate multiple candidate sites before a project became real.

sunpower geo 03 — Project setup captured customer, site, and team context.

The modal captured the basic project structure, project name, customer, Salesforce ID, team, KMZ upload, and location, while keeping the map visible in the background.

That preserved context. Users were not taken away from the planning surface just to create a record.

diagram geo 02 — GEO turned map geometry, configuration, simulation, and outputs into one planning model.

Making simulation part of the design workflow

Simulation was not treated as a separate analysis step. It was embedded into the same map-based workflow.

The simulation controls let users adjust product type, ground coverage ratio, DC/AC ratio, and other key assumptions before running analysis.

sunpower geo 04 — Simulation controls let teams test system assumptions against real terrain.

Product selection allowed teams to compare tracker and system options without leaving the site context.

sunpower geo 05 — Product configuration supported fast comparisons across system options.

Parameter tuning gave the workflow a more exploratory feel. Users could adjust assumptions and immediately understand that the design was not fixed. It was a model to be tested.

sunpower geo 06 — Parameter tuning helped teams explore performance and density tradeoffs.

The interface had to make this complexity manageable. Too much engineering detail would slow the user down. Too little would make the output feel untrustworthy.

Showing progress while analysis ran

Simulation can feel opaque when the user has no feedback. GEO used a progress state to make the system’s work visible.

sunpower geo 07 — Simulation feedback made long-running analysis feel transparent.

This kind of interaction matters in technical tools. When analysis takes time, the interface needs to reassure the user that something real is happening and that the system is processing the selected assumptions.

Comparing results instead of forcing one answer

The simulation results view translated analysis into decision-ready comparisons: capacity, yield, specific yield, performance ratio, capacity factor, and alternative configurations.

sunpower geo 08 — Results compared capacity, yield, and performance alternatives.

This let teams move from “run a simulation” to “compare tradeoffs.” The product surfaced alternatives so users could reason through density, capacity, performance, and production instead of accepting a single opaque recommendation.

Moving from feasibility into detailed design

After simulation, GEO supported a more detailed design mode. The interface showed estimated modules, GCR, DC/AC ratio, tilt, azimuth, tracker system, module selection, inverter selection, and layout optimization controls.

sunpower geo 09 — Detailed design controls translated simulation into layout decisions.

This step connected high-level feasibility to practical system configuration. The design controls made the planning model editable, not just reportable.

Connecting design work to proposal output

The final step was output. GEO connected project summary data, system details, annual production, bill of materials, component costs, and financial analysis into a proposal-ready view.

sunpower geo 10 — Proposal output connected site planning to cost and equipment decisions.

This closed the loop between geospatial analysis and business communication. A site plan was no longer isolated from the commercial conversation. It could feed the proposal, the BOM, and the next decision.

Outcome

GEO made early solar planning more connected and decision-ready.

GEO gave utility-scale teams a clearer way to move from a potential site to a structured project plan. It connected geospatial context, system assumptions, simulation results, design controls, and proposal outputs into one working environment.

diagram geo 03 — GEO moved projects from site definition to simulation, design, and proposal readiness.

Estimated impact based on project context:

Faster early-stage site evaluation
Clearer comparison of product and configuration alternatives
Better continuity between mapping, simulation, and proposal work
Reduced manual translation between planning tools and business outputs
More confidence when evaluating capacity, yield, and layout tradeoffs
A stronger foundation for utility-scale solar project planning

The project mattered because it treated solar planning as an integrated system. GEO connected spatial reasoning, engineering assumptions, and commercial outputs into one product experience.