# Zaki Gouizi

> Engineer and Enka co-founder building applications, automation and data workflows. I connect product needs with interfaces, backend systems and the way people use them.

## Work I can help with

I work across software, data and automation. My strength is connecting the parts of a problem: understanding the need, designing the workflow, building the application and making the information move between the right people and tools.

- **Build a product across frontend and backend.** At [Enka](https://zaki.somehow.engineer/read/en/enka.md), I am co-founder and CTO, working across customer ordering, courier workflows and administration. My earlier [StudentBank internship](https://zaki.somehow.engineer/read/en/studentbank.md) covered user interviews, modeling, React interfaces and backend development.
- **Turn repetitive computer work into a usable tool.** [Murmur](https://zaki.somehow.engineer/read/en/murmur.md), [Screen to Calendar](https://zaki.somehow.engineer/read/en/screen-to-calendar.md) and my [prospecting workspace](https://zaki.somehow.engineer/read/en/prospecting-workspace.md) grew from practical needs: dictation, moving information into a calendar, and keeping research and outreach drafts organized.
- **Connect AI generation to a reviewable workflow.** [Flow Studio](https://zaki.somehow.engineer/read/en/flow-studio.md) brings prompts, image and video generation, versions and feedback into a working interface. My [Thinking Partner](https://zaki.somehow.engineer/read/en/thinking-partner.md) explores how questions, evidence and revisions can support longer research.
- **Investigate a forecasting or data question.** At [Decathlon](https://zaki.somehow.engineer/read/en/decathlon.md), I worked on forecasting covariables, including weather, holidays and events. My [crypto research](https://zaki.somehow.engineer/read/en/crypto-research.md) shows the same willingness to investigate a question deeply, inspect the experiment and change the conclusion when the evidence changes.
- **Contribute to a project that needs technical and creative thinking.** Alongside engineering, I co-preside over [Recto Verso](https://zaki.somehow.engineer/read/en/recto-verso.md), an association for art, photography and visuals. I also contribute camera work and ideas to [friends’ films](https://zaki.somehow.engineer/read/en/filmmaking.md), and I am learning to [make clothes](https://zaki.somehow.engineer/read/en/clothes.md).

For freelance work, I collaborate with a small team across automation, cybersecurity, marketing and content creation. We shape the scope around the client’s needs and the strengths of the people involved.

## What connects these projects

I like taking a problem beyond the first idea. Enka connects an application with restaurant and courier operations. StudentBank connected user journeys with interfaces and a data model. My automation projects turn repeated actions into tools I can return to and use.

That is the kind of work I want to do more of: turn a need into a clear workflow, build the useful parts and keep improving them through use. I am developing my freelance activity and looking for opportunities in Paris and abroad.

## Hi, I’m Zaki.

> An engineering background, software and data experience, and a freelance journey alongside a search for opportunities in Paris and abroad.

Welcome to my portfolio

Category: Welcome

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#welcome/27>)

[Français](<https://zaki.somehow.engineer/profile.fr.md>)

### A little about me

I’m Zaki Gouizi, an engineer with a computer science background from JUNIA HEI in Lille, following preparatory studies at Lycée LaSalle.

I’ve worked on forecasting at Decathlon and full-stack development at StudentBank. I’m also co-founder and CTO of Enka.

I’m developing my freelance work with a small team of collaborators, offering automation, cybersecurity, marketing, content creation and other services based on each client’s needs. Alongside that, I’m looking for job opportunities in Paris and abroad.

### Related work

- [My studies](<https://zaki.somehow.engineer/read/en/engineering-studies.md>)
- [Decathlon](<https://zaki.somehow.engineer/read/en/decathlon.md>)
- [StudentBank](<https://zaki.somehow.engineer/read/en/studentbank.md>)
- [Enka](<https://zaki.somehow.engineer/read/en/enka.md>)

## How I approach my work

I'm Zaki, an engineer and co-founder of Enka. When I run into a problem, my first question is often: “Would it be faster to make it myself?”

That's why I became an engineer: to have the tools to turn my ideas into something I can use. Sometimes that means automating an annoying task. Sometimes it means spending months exploring a question until I understand it for myself.

My interests also take me into building a business, helping friends make films, and learning to sew my own clothes. These are some of the things I've made and what I've learned along the way.

## Contact

- [Email me](<mailto:zakigouizi@gmail.com>)
- [Open LinkedIn](<https://www.linkedin.com/in/zaki-gouizi/>)
- [Open GitHub](<https://github.com/zakich4n>)


## Tools & research

### Murmur

> Local French and English dictation, from a spoken thought to usable text.

Personal application · macOS · October 2026

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/0>)

[Français](<https://zaki.somehow.engineer/read/fr/murmur.md>)

#### Start with the machine

Murmur is a French and English dictation app built around local speech recognition. I started by measuring what an Intel Mac could run, then built a native menu-bar application around recording, transcription and optional text cleanup.

The benchmark machine had a six-core Intel Core i7 and 16 GB of memory. In recorded CPU tests, the transcription engine processed separate 20-second synthetic French and English clips in approximately 3.74 seconds each. These measurements included model startup and loading, but excluded recording and interface overhead. They were a useful starting point, not a measure of accuracy on everyday speech.

#### Separate recognition from editing

Whisper produces the raw transcript. An optional Qwen stage cleans up the text, while the original remains available. Speech detection helps handle silence, and empty recognition skips the cleanup stage.

The app integrates existing engines and models through whisper.cpp and llama.cpp. My work was building the application and coordinating those components.

#### Make the surrounding behavior dependable

Much of the work concerned what happens around inference: cancellation, errors, history and text insertion. Cancelling a task needs to stop its processes. A failed cleanup should leave the original text recoverable. If the user changes focus, the app needs to avoid inserting text into the wrong place.

The Swift application handles these states and provides insertion or clipboard paths. It also keeps the Python benchmarking setup separate from the app's runtime.

#### Current state

The project produced a locally installed app with recorded engine and lifecycle checks. Broader desktop testing—including physical shortcuts, microphone behavior and insertion across applications—remains incomplete. It is a personal application under development.

Murmur captures a part of engineering I enjoy: taking a capable model and doing the surrounding work that lets it fit into an ordinary task.


### Crypto research

> Months of models, wallet analysis and paper trading—and learning to question the experiment itself.

Personal research · 2026

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/1>)

[Français](<https://zaki.somehow.engineer/read/fr/crypto-research.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Personal research & development |
| Period | 2026 · several months |
| Data | 15-minute candles · 22 tokens |
| Trading | Paper mode · Telegram monitoring |

#### The question

I spent months exploring whether I could find a useful signal in crypto market data. I wanted to understand the problem for myself, so I built tools to study wallet behavior, trained models on price histories, explored Reddit text and ran paper-trading bots with Telegram monitoring.

#### Building the experiments

The work grew across several projects. Wallet analysis involved collecting transactions and reconstructing positions. A price-modeling pipeline used 15-minute candles across 22 tokens, with roughly 1.49 million recorded candle rows. More than 1,000 candidate features were narrowed to 300 for modeling.

Different experiments asked different questions. Predicting a future price direction and identifying current market conditions are separate tasks, even when their scores appear beside each other. I also studied whether collective buying and selling by large wallets contained a useful signal.

Python · Pandas / Parquet · LightGBM · Optuna · SQLite · Telegram

| Value | Metric |
| --- | --- |
| 22 | Tokens studied |
| ≈ 1.49M | Recorded candle rows |
| 300 | Selected features |
| 4 h | Direction-label horizon |

#### The result that changed the story

Some early results looked very strong. Comparing historical calculations with the information available during paper trading exposed future information in the features. Completed hourly bars were being used at timestamps before those bars had finished, and a decomposition method used later data when calculating earlier values.

The correction used completed past bars and trailing windows. In the recorded rebuild, direction accuracy fell from 65.7% to 43.3%. That changed what I could conclude from the experiment.

| Value | Metric |
| --- | --- |
| 65.7% | Before correction · invalidated |
| 43.3% | After correction |
| −22.4 pp | Accuracy difference |

> Regime accuracy remained around 91.7%, but that model classified current market conditions. It did not predict future prices, so its score is not comparable to direction accuracy.

##### Images and media

[Correcting the features lowered the score and changed the interpretation. The earlier result is invalidated.](<https://zaki.somehow.engineer/content/assets/crypto/case-study/direction-correction.en.png>)

Recorded direction accuracy: invalidated 65.7% before correction and 43.3% after, a 22.4 percentage-point decrease.

[SVG](<https://zaki.somehow.engineer/content/assets/crypto/case-study/direction-correction.en.svg>)

Credit: Chart prepared for this portfolio from the 21 March 2026 research decision, recorded in the review notes. Experiments not rerun.

[One corrected leakage mechanism: use the last genuinely completed candle. Explanatory schematic, not market-price data.](<https://zaki.somehow.engineer/content/assets/crypto/case-study/completed-candle.en.png>)

Schematic showing that at 00:15 the 00:00–01:00 candle is unfinished, while the preceding completed candle is available.

[SVG](<https://zaki.somehow.engineer/content/assets/crypto/case-study/completed-candle.en.svg>)

Credit: Chart prepared for this portfolio from the documented completed-bar correction. Experiments not rerun.

#### Test other sources of signal

I also studied collective activity from large wallets. The saved whale-flow report examined 1,470 consensus-filter combinations; none survived its stated multiple-testing correction. That finding concerned the tested setup, rather than proving that all market signals are unusable.

Another avenue used MiniLM embeddings of Reddit text and a learned projection. The contrastive-learning report recorded 268,975 training posts, 18,748 held-out test posts and 50.5% held-out post accuracy. Its conclusion was “NO SIGNAL”. This was a different task from the three-class price-direction model.

##### Images and media

[The scale and result of a separate text experiment, without comparing its accuracy directly to the price model.](<https://zaki.somehow.engineer/content/assets/crypto/case-study/reddit-experiment.en.png>)

Reddit split sizes: 268,975 training posts and 18,748 held-out test posts; recorded post accuracy 50.5%, with a no-signal report conclusion.

[SVG](<https://zaki.somehow.engineer/content/assets/crypto/case-study/reddit-experiment.en.svg>)

Credit: Chart prepared for this portfolio from the saved Reddit contrastive report, recorded in the review notes. Experiments not rerun.

#### Follow whales with a paper-trading bot

I built a bot that watched selected large wallets and used their activity to trigger simulated positions, with Telegram monitoring. That turned the wallet research into an end-to-end experiment: detect a signal, open a paper position, follow it and record the exit.

The bot’s monitoring reported roughly +28 SOL in paper PnL. The later audit reconciled the final reset period, from 13 April to 18 May 2026, to +27.63 SOL-labelled units across 1,367 matched closed positions, starting from 11.81 units of simulated capital. The original monitoring filter showed +28.40; normalizing the timestamps included additional losses.

It was an encouraging milestone after months of research: the whale-following pipeline was running and producing a positive result in its own simulation. I then examined how much of that result depended on the simulator’s assumptions and a few exceptional recorded winners.

The broader crypto-follow ledger contains 4,515 buys and 4,435 sells from 2 April to 18 May 2026, all paper-marked. Those 8,950 rows count buys and sells separately and cover a longer period than the final-reset result above. The code connected them to Telegram alerts labelled [PAPER].

| Value | Metric |
| --- | --- |
| ≈ +28 | SOL-labelled paper PnL |
| 1,367 | Matched closed positions · final period |
| 11.81 | Initial simulated capital · SOL units |

> Historical simulator result, not verified SOL profit. The later audit found accounting, currency-conversion and fill-price limitations; the next section explains the sensitivity checks.

##### Images and media

[8,950 records does not mean 8,950 completed positions. This chart shows recorded activity, not profitability.](<https://zaki.somehow.engineer/content/assets/crypto/case-study/paper-records.en.png>)

4,515 buys and 4,435 sells, totaling 8,950 individual paper-trading records.

[SVG](<https://zaki.somehow.engineer/content/assets/crypto/case-study/paper-records.en.svg>)

Credit: Chart prepared for this portfolio from read-only SQLite aggregates recorded on 5 November 2026. Experiments not rerun.

#### Check what the simulator actually measures

A later saved historical audit identified accounting, currency-conversion and simulated-fill limitations. Correcting cash calculations alone did not validate the strategy: exceptional recorded winners still dominated the results.

In a replay with recalculated position sizing, the saved result moves from +29.09 SOL-labelled units to +2.07 when two flagged winners are excluded, and to −6.30 without the five largest winners. These are retrospective exclusions using returns whose fill prices remain unverified. They test sensitivity, rather than establishing real profit or a repaired strategy.

I later adapted an existing automated-research framework to organize continued experiments around a fixed dataset, baselines and clearer comparison rules. The work became as much about the reliability of the experiment as the choice of model.

The adapted harness log contains 384 entries spanning baselines, trials, crashes and restored candidates. That is not a count of 384 independent successful experiments. Comparisons need to stay within the same target definition.

> The charts are newly drawn, but their values come from saved reports and analyses. No bot, training run or trading replay was restarted to produce them.

##### Images and media

[Saved replay scenarios from 14 October 2026. Exclusions are retrospective; the chart does not describe real profits.](<https://zaki.somehow.engineer/content/assets/crypto/case-study/replay-sensitivity.en.png>)

Saved replay sensitivity: +29.09 units, +2.07 excluding two flagged winners, −6.30 excluding the five largest; historical fill prices unverified.

[SVG](<https://zaki.somehow.engineer/content/assets/crypto/case-study/replay-sensitivity.en.svg>)

Credit: Chart prepared for this portfolio from the saved 14 October 2026 cash replay. Experiments not rerun.

#### What stayed with me

This is one of the projects that feels most like me. I followed a question long enough to understand why some promising answers did not hold up. It gave me experience in data engineering, modeling and operational debugging, and made me more careful about what a result actually demonstrates.

The figures above come from saved experiment records. They describe those experiments, not current predictive performance or a profitable trading strategy.


### Flow Studio

> A visual workspace connecting references, prompts, versions and feedback around Google Flow.

Personal tooling · Creative automation

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/2>)

[Français](<https://zaki.somehow.engineer/read/fr/flow-studio.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Application & automation |
| Workspace | Graph · versions · review |
| Generation | Google Flow |
| Example | Existing Coco Romy production |

#### Keep the creative thread

Generating images and videos involves more than a prompt. References, earlier results and requests for changes need to stay connected. I built Flow Studio to keep that work in one visual workspace, with a browser adapter for Google Flow.

These captures use Coco Romy, an existing generated production in my workspace. They show a real project with its images, prompts, versions and clips, rather than a reconstructed interface.

##### Images and media

[The graph keeps the relationships visible; the inspector provides the selected node’s complete content.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/image-details.webp>)

Flow Studio graph connecting images, prompts and video shots, with the selected image and its instructions in the inspector.

Credit: Flow Studio · existing Coco Romy production. Captured 9 November 2026.

#### Connect instructions to their results

The work is organized into nodes for prompts, references, images, videos and review steps. An image keeps its instructions and references; the connected video shot retains the context of the image it uses.

The aim is to revisit a decision without having to reconstruct which file belonged to which version. The graph makes the sequence readable, while the store retains identifiers, settings and downloaded files.

TypeScript · React · React Flow / XYFlow · File-backed state · Google Flow

From brief to generated shot

1. **Prompt** — Define the scene, references and what must be preserved.
2. **Image** — Review the result and retain its versions.
3. **Video** — Connect the shot to its image and animation instructions.

A simplified reading of the workflow visible in the existing project.

#### Revise an image without losing earlier versions

In this example, the requested change was specific: swap the characters’ positions on the scooter while preserving their identities, clothes and lighting. The approved version places Coco at the handlebars and Romy behind him.

History retains the first version, the agent’s revision and the approval state. Earlier instructions remain available to inspect, compare as text and restore without erasing what happened afterwards.

##### Images and media

[Version 1, preserved in history.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/coco-romy-keyframe-v1.webp>)

Earlier generated version with Romy at the front of the scooter and Coco behind.

Credit: Coco Romy · Google Flow-generated image, existing project archive.

[Approved version 2: the seating changes while the scene remains recognizable.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/coco-romy-keyframe.webp>)

Revised version with Coco driving and Romy behind him in the same dawn street.

Credit: Coco Romy · Google Flow-generated image, existing project archive.

[The earlier result and its instructions remain accessible from the same node.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/version-history.webp>)

History tab showing both image versions and the earlier instructions.

Credit: Flow Studio · existing Coco Romy production. Captured 9 November 2026.

#### Turn feedback into actionable work

Review offers three decisions: approve, comment or request changes. Submitted feedback is tied to the version being reviewed and becomes a task the agent can read. A revised result returns as a new version of the same node.

That lets me specify what should change and what should remain consistent. Review history and task acknowledgements keep the feedback connected to the revision.

##### Images and media

[A demonstration draft entered for the capture and then cleared. No new feedback was submitted to the existing production.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/review-controls.webp>)

Review tab with a Portfolio demo draft and Approve, Comment and Request changes actions.

Credit: Flow Studio · existing Coco Romy production. Captured 9 November 2026.

#### Carry the image into a video shot

The video shot keeps its image and motion instructions close at hand. Its detail panel makes it possible to inspect the scene and continuity requirements before approving the result.

The clip below comes from an existing Coco Romy generation. It runs for about eight seconds, in portrait 720 × 1280 at 24 frames per second. This take is still awaiting review in the workspace; it is shown as a concrete output example rather than an approved final film.

##### Images and media

[The clip, its instructions and its Ready for review state in one view.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/video-details.webp>)

Selected video node with playback paused at one second and its animation instructions in the detail panel.

Credit: Flow Studio · existing Coco Romy production. Captured 9 November 2026.

[Existing Coco Romy scene 13, second take. Click to play.](<https://zaki.somehow.engineer/content/assets/flow-studio/case-study/coco-romy-scene13.mp4>)

Generated clip of Coco and Romy on a scooter in a Riviera street at dawn.

Credit: Generated with Google Flow, 3 November 2026. Optimized portfolio copy; scene and audio retained.

#### Recover a result without regenerating it

Generation and downloading are separate steps. If retrieval fails after generation finishes, the system retains the information needed to recover the existing asset before submitting another paid request.

This is less visible in the graph, but it matters in a tool that needs to resume after interruptions. Operation states, identifiers and version relationships all serve the same purpose: preserving what actually happened.

#### My contribution and the project’s scope

My work is the production workspace, persistence, review and automation around Google Flow. The generation models and Google Flow itself are existing tools. Some generation combinations remain partial or depend on the upstream interface and account state.

These captures were taken in the live app on 9 November 2026 using an existing production. They demonstrate the workflow without claiming a measured time saving or universal reliability.


### Screen to Calendar

> Turn copied text or a screenshot into an event you can review and save to Apple Calendar.

Personal application · Swift / macOS

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/3>)

[Français](<https://zaki.somehow.engineer/read/fr/screen-to-calendar.md>)

#### Why type it twice?

Event details often arrive in a message, an image or a page. I built a menu-bar tool to extract the title, date, time and location, then prepare a calendar entry.

#### Keep a review step

The app uses local model processing through Ollama and OCR for visual input. Dates and event details can be ambiguous, so the extracted fields remain editable before saving. The project is still a work in progress.

#### Links

- [View on GitHub](<https://github.com/zakich4n/screen-to-calendar>)


### Video outpainting

> Expand a video’s canvas by generating the missing regions, with a focus on consistency from frame to frame.

Personal project · Experimental tooling

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/4>)

[Français](<https://zaki.somehow.engineer/read/fr/video-outpainting.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Prototype & integration |
| Goal | Adapt a video’s format |
| Challenge | Consistency over time |
| Stage | Experimental prototype |

#### Change the format while keeping the scene

The end goal was to adapt footage to another frame by generating what is missing around the image. That can mean widening a 4:3 video to 16:9 or preparing a portrait composition from a landscape shot.

My prototype initially focused on the second case: placing landscape footage inside a portrait canvas and filling the areas above and below it. The 4:3-to-16:9 example below explains the general idea; it is not a measured result from my code.

##### Images and media

[At the same height, the source occupies 75% of the 16:9 frame and each added side band 12.5%. These are geometric proportions, not model-quality scores.](<https://zaki.somehow.engineer/content/assets/outpainting/case-study/format-concept.en.svg>)

Diagram showing the retained 4:3 source in the middle of a 16:9 target with newly generated side bands.

Credit: Explanatory diagram created for this portfolio. No generated output is implied.

#### What video outpainting looks like

Seen-to-Scene’s examples make the idea visible on real sequences: observed content remains recognizable while the visible field is extended. The examples below come from InSeok Jeon and his coauthors’ research project.

They illustrate the kind of outcome I wanted to work towards, rather than outputs from my prototype. I did not implement or train Seen-to-Scene; my project explores its own orchestration of diffusion and motion-guided propagation.

##### Images and media

[External illustration: source sequences and expanded results published by the Seen-to-Scene authors. These are not my results.](<https://zaki.somehow.engineer/content/assets/outpainting/case-study/seen-to-scene-teaser.webp>)

Seen-to-Scene montage of dog and motocross sequences, showing source views and expanded results.

Credit: [© 2026 InSeok Jeon and coauthors · Seen-to-Scene · MIT-licensed repository.](<https://github.com/InSeokJeon/Seen_to_Scene/tree/2a9dfc9888e44c7fd00b08af41ef967ae46b6323>)

[External demonstration from the authors’ GIF, converted to a click-to-play preview. Its 25 frames are presented at 10 frames per second.](<https://zaki.somehow.engineer/content/assets/outpainting/case-study/seen-to-scene-demo.mp4>)

Grid of eight animated video-outpainting examples published by Seen-to-Scene.

Credit: [InSeok Jeon and coauthors · Seen-to-Scene, 2026. Authors’ source and method.](<https://github.com/InSeokJeon/Seen_to_Scene>)

#### The hard part: keeping the surroundings consistent

A single expanded frame can look convincing. In a video, textures, objects and lighting also need to stay coherent as the camera or subjects move. Generating every frame independently can produce surroundings that change or flicker.

The pipeline uses estimated motion to warp the preceding generated frame and initialize the next fill. It also computes a propagated latent-noise state, but this version does not yet pass that state into the inpainting call. That part of the intended continuity mechanism remains unfinished.

#### Build a pipeline I can inspect

The code separates frame extraction, canvas and mask preparation, motion estimation, propagation, filling and clip reconstruction. It also provides a deflicker stage and audio reassembly.

Generation uses a Diffusers inpainting integration. A deterministic fill mode lets me test the pipeline mechanics without running the model. The stages are configurable so I can isolate a problem or replace an implementation.

Python · Diffusers · Optical flow · Latent propagation · SSIM / optional LPIPS

A clip’s path through the prototype

1. **Prepare** — Extract frames, build the canvas and mask the areas to fill.
2. **Propagate & generate** — Estimate motion, carry preceding state and fill the missing areas.
3. **Inspect & assemble** — Collect diagnostics, apply post-processing and rebuild the video.

Summary of the code reviewed for this entry. This describes my prototype, not Seen-to-Scene’s architecture.

#### What I tested, and what remains

One saved short run contains three adjacent-frame comparisons: mean SSIM 0.9239 and mean flow-warped temporal error 3.5450. These values help inspect that small run. They do not mean “92% visual quality” and are not a controlled comparison against another method.

The end goal remains a format-adaptation tool I could evaluate across varied scenes, with the source frame and generated regions clearly identified. I still need representative outputs across a wider range of scenes to judge the visual result.

| Value | Metric |
| --- | --- |
| 3 | Comparisons in the short run |
| 0.9239 | Mean SSIM · local short run |
| 3.5450 | Mean temporal error · code-specific scale |

> Diagnostics come from an existing result file reread on 9 November 2026. No training or new generation was run. The exact settings for this run and a comparison baseline are not established.

#### Links

- [Seen-to-Scene · visual examples & source](<https://github.com/InSeokJeon/Seen_to_Scene>)
- [Seen-to-Scene · MIT license](<https://github.com/InSeokJeon/Seen_to_Scene/blob/2a9dfc9888e44c7fd00b08af41ef967ae46b6323/LICENSE>)


### Thinking Partner

> A research workspace that keeps questions, evidence and revisions connected, even when I change direction.

Personal project · AI-assisted research workflow

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/5>)

[Français](<https://zaki.somehow.engineer/read/fr/thinking-partner.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Workflow design & implementation |
| Workspace | Markdown / Obsidian |
| Workflows | Explore · Check · Write · Review |
| Stage | Experimental v1 |

#### Keep the reasoning, not just the answer

A long conversation can contain a useful question, a source, a disagreement and a change of mind. Finding how they connect later is another problem. I built Thinking Partner to give that work a place outside the conversation.

The idea is to keep a question open long enough to explore it properly. Different directions remain visible, claims stay attached to their evidence, and revisions leave a trace. It is a tool for working through a subject, with AI assistance and room for my own judgment.

#### Choose a direction, then come back

An exploration starts with the question and a map of possible directions. I can select several, add a comment to one branch, suggest another interpretation or leave part of the work for later. An independent omission check is designed to look for angles the initial map missed.

Those choices are saved. Pausing, redirecting the investigation or switching towards a draft preserves earlier evidence and unanswered paths. A new direction archives the previous research round and marks the old synthesis as superseded, so it cannot silently pass for the latest conclusion.

#### Make an assertion inspectable

The claim ledger distinguishes factual assertions, interpretations, hypotheses and values. Each source can be linked to the claim it supports, with a locator, access information and an audit record. Reading an abstract is recorded as abstract-only access; it does not become a claim to have checked the full paper.

Initial contributions can be committed before researchers exchange positions. Later disagreements, concessions and revisions remain visible. When a claim or its evidence changes, the previous audit becomes stale and needs checking again.

From a question to a draft

1. **Map** — Record the question, select branches and keep unresolved directions visible.
2. **Check** — Connect claims to sources, inspect support and record what changed.
3. **Write** — Reuse current audited material, then review the argument and its limits.

The intended research cycle. The software records and checks the state; the agents still need to inspect and interpret the sources.

#### Write without losing the source

The four workflows cover exploration, fact-checking, writing and review. A draft can reuse exact factual passages from audited claims through locked text spans. Changing their meaning requires another audit. Reports and drafts are versioned alongside the research.

That guard protects a precise passage, not every implication in the surrounding prose. The review workflow therefore separates argument, factual support, style, audience and the strongest opposing case. The available role profiles are a menu: only the perspectives useful to the question should run.

#### A small implementation I can inspect

I kept the implementation close to the tools I already use: dependency-free Node scripts, a structured JSON state and linked Markdown views. Home, Map, Claims, Evidence, Debate, Sources and Synthesis let me move from an overview to the supporting detail in Obsidian, without a custom plugin.

The v1 extension snapshots an existing topic before adding its new state. Repeated requests have replay protection, and generated-note edit checks flag manual changes that need reconciliation. Codex supplies the model runtime and agent orchestration; Obsidian is the note interface. My work here is the workflow, persistence and checks around those tools.

In Obsidian’s graph view, each dot represents a note and each line a link between notes. A small map makes those connections easy to follow. As a vault grows, its graph can reveal clusters and bridges between subjects, although the number of connections says little about the strength of the evidence.

The simple graph shown here is an external Obsidian example. The denser MIT-IBM Paper Graph image illustrates a broader network of research relationships. Neither is a screenshot or output of Thinking Partner. This prototype organizes individual explorations and their evidence; it does not implement a global knowledge graph.

Node.js · Markdown · JSON state · Codex · Obsidian

##### Images and media

[Start with the basics: each circle is a note, each connecting line an internal link. A small graph makes relationships easy to follow.](<https://zaki.somehow.engineer/content/assets/thinking-partner/case-study/obsidian-basic.webp>)

A small Obsidian graph with named notes joined by visible links.

Credit: [XDA · External Obsidian graph-view example.](<https://static0.xdaimages.com/wordpress/wp-content/uploads/wm/2024/07/how-to-use-obsidian-graph-view-1.jpg?q=49&fit=crop&w=825&dpr=2>)

[A larger research network: papers, citations, authors and affiliations form a dense map. This illustrates the potential complexity of connected knowledge; it is not an Obsidian graph or a Thinking Partner result.](<https://zaki.somehow.engineer/content/assets/thinking-partner/case-study/paper-graph-complex.webp>)

MIT-IBM Watson AI Lab Paper Graph interface showing a dense network of papers, citations, authors and affiliations.

Credit: [MIT-IBM Watson AI Lab · Paper Graph interface, shared on the Obsidian community forum.](<https://forum.obsidian.md/uploads/default/8f4c01b19341de85a2e849750bf76c0b33f87452>)

#### What is tested, and what is still open

The recorded v1 implementation run passed 31 deterministic tests with no failures. These cover storage and workflow behavior, including pause/resume, stale results, evidence-access distinctions, snapshots and generated-note protection. A separate synthetic demonstration produces the linked notes and session history.

Those checks establish that the mechanics behave as expected. They do not establish that the research is accurate, the perspectives are genuinely independent or the final argument is useful. A live pilot across two topics remains the next quality check. I have no measured accuracy gain, time saving or reliable development-hour total to report.

| Value | Metric |
| --- | --- |
| 31 | Tests passed · recorded v1 run |
| 0 | Failures · same run |

> The test figures come from the existing v1 implementation record, not a new test run for this portfolio. Synthetic demonstrations are not research results. Independent contexts and source fidelity still depend on how the workflow is executed.


### Video distribution pipeline

> From a source video to clips ready for review in TikTok: a persistent workflow that keeps its place, tracks delivery and leaves publication in my hands.

Personal project · Workflow automation

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/6>)

[Français](<https://zaki.somehow.engineer/read/fr/video-distribution-pipeline.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Durable orchestration & integration |
| Core stack | Python · SQLite · FFmpeg |
| Controls | Telegram & local commands |
| Rendering policy | 1 downloader + 1 encoder |
| Delivery | Account-specific TikTok Inbox |
| Final publication | Manual review & posting |

#### Automate the work between a video and its publication

Preparing clips is a chain of small operations: download a source, find the parts, render a portrait version, choose an account, transfer the files and check that they arrived. Repeating those steps manually means keeping track of what has already happened and what still needs attention.

I built a persistent orchestration layer around an existing portrait-rendering workflow. It carries each source through preparation and delivery, with a queue I can inspect and control from Telegram. The destination is TikTok’s Inbox, where the clips can be reviewed before publishing.

One source, six stages

1. **Add a source** — Submit a YouTube URL through Telegram or a local input file. The video ID prevents duplicate queue entries.
2. **Download & analyze** — Keep the source media, determine its parts and give it a short code for later commands.
3. **Render the clips** — Prepare portrait clips through the existing scene-aware rendering path. Keep completed files available for the next stage.
4. **Route & transfer** — Assign an account, keep the parts together and initialize uploads in their original order.
5. **Confirm delivery** — Check the recorded upload ID until Inbox delivery or a failure is confirmed. Send the delayed Telegram alert separately.
6. **Review & publish** — Open TikTok, review the clip and decide whether to publish. The pipeline does not make that decision.

This describes the implemented workflow. A fresh live upload was not performed for this portfolio entry.

#### Keep the right clips on the right account

Multiple accounts make scheduling more involved than taking the next file in a folder. The pipeline assigns sources according to unfinished work, then prioritizes rendering according to the clips already waiting for each account. One downloader and one encoder run at a time; upload and delivery workers are separate for each account.

All parts from a source stay attached to the same account. A later part cannot start uploading until earlier parts have reached the required delivery state. If the first part fails or has an uncertain outcome, the next part waits rather than leaving a gap in the sequence.

Accounts use stable internal identities instead of display names. Pauses survive a restart, and disabling an account stops new work while allowing delivery checks on accepted uploads to continue.

#### Recover without guessing what happened

The difficult case is a request that may have succeeded remotely just before the local process stopped. Automatically trying again could send the same clip twice. I separate upload acceptance, byte transfer, Inbox delivery, failure and publication instead of treating them as a single “done” state.

SQLite stores the queue, clip boundaries, upload attempts, account pauses and pending notifications. The upload initialization ID is saved before bytes are sent. After a restart, known IDs continue receiving status checks; an uncertain acceptance is held for human review instead of automatically creating another upload.

Completed downloads and renders are retained. Transactions claim work, and a process lock prevents two service instances from working the same queue. Migration also preserves old state and holds ambiguous historical uploads for review.

> The notification boundary is different: Telegram delivery is at least once. A crash after Telegram accepts an alert but before the local record is saved can still duplicate that alert.

#### Stay in control from Telegram

Telegram is both an input and a control surface. After pairing a private owner chat, I can add a source, inspect the queue, check account status, pause or resume processing, assign an untouched source and explicitly retry a confirmed failure. Short source codes make these actions manageable without copying long identifiers.

Alerts have their own delivery queue, so a failed notification does not require repeating the video transfer. An alert is eligible only after confirmed Inbox delivery and at least 15 minutes after the transfer. The pause command lets the current operation finish, and delivery checks continue for work already accepted.

> The default local policy allows one initialized or uncertain share per account in a rolling 24 hours. That is a conservative scheduling setting, not a measured TikTok quota or a throughput result.

#### My contribution and the tools underneath

My focus was the Python orchestration: durable state, account routing, ordered jobs, recovery rules and human controls. I developed the project with AI coding agents, following my usual workflow.

The project reuses an existing scene-aware portrait-rendering path and relies on FFmpeg/FFprobe for media processing, TikTok for upload and delivery status, and Telegram for commands and alerts. I am presenting the integration and queue design here; I am not claiming to have invented every media-processing component.

Python · SQLite · FFmpeg / FFprobe · TikTok API · Telegram bot · Persistent queue

#### What is established, and what still needs a live run

The repository includes tests using temporary SQLite databases and mocked network calls for account identity, routing, isolated account limits, restart recovery, pairing, command replay, migration and notification retries. Those tests were not rerun for this portfolio review, and they do not establish that a live clip reached an account.

I have not established a verified end-to-end deployment result, a measured processing-time gain or audience-growth figures for this entry. The documented service runs on macOS and stops when the machine sleeps or powers off. Moving an existing workspace to another machine also requires updating its stored media paths.

The project shows the part of automation I find most interesting: deciding what the system can safely repeat, what it needs to remember and when it should ask for a human decision. Here, success means keeping a workflow understandable even when one of its steps fails.

> Development hours and total video volume were not recorded. The concurrency, alert delay and scheduling window above describe configuration, not measured performance.


### Brainrot or Not

> An experimental media interface around Meta’s TRIBE v2: brain-response visualizations, custom summaries and a question about what they could bring to editing.

Personal project · AI & media experiment

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/7>)

[Français](<https://zaki.somehow.engineer/read/fr/brainrot-or-not.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Interface & model integration |
| Research model | Meta · TRIBE v2 |
| Inputs | Video · Text · Image |
| Stage | Exploratory prototype |

#### A question from filmmaking

Could a model give me another way to look at a video? I was curious about the possibility of spotting moments that might deserve a different edit, then comparing versions. Brainrot or Not grew out of that question and my interest in trying emerging research for myself.

I built an experimental interface around a pretrained brain-response model, with media inputs, visualizations and my own summary scores. The name is playful; the underlying question is how much useful information I can actually draw from those outputs.

#### The research underneath

TRIBE v2 is Meta’s multimodal model for predicting fMRI brain responses to video, audio and language. Meta describes training on recordings from more than 700 volunteers. The released inference tools produce predictions for an average subject on a cortical surface, rather than measuring the person watching my interface.

That research supplies the pretrained model. My contribution is the application around it: preparing inputs, invoking the model and exploring how to present its outputs. The animation below is Meta’s explanation of the research, not a recording of my prototype.

##### Images and media

[External research illustration: Meta explains the relationship between media stimuli and predicted brain responses. This is not an output from Brainrot or Not.](<https://zaki.somehow.engineer/content/assets/brainrot/case-study/meta-tribe-explainer.mp4>)

Meta animation connecting media stimuli with predicted activity on a brain surface.

Credit: [Meta AI · TRIBE v2 announcement, 26 March 2026. Video resized for this portfolio; original audio omitted.](<https://ai.meta.com/blog/tribe-v2-brain-predictive-foundation-model/>)

#### Make the model explorable

The Gradio interface exposes three input paths: video, text and image. The preparation code trims video and can turn a still image into a video representation for the model’s event-building path.

The app loads facebook/tribev2, builds the input events and calls the model’s prediction interface. Nilearn utilities then help turn the resulting arrays into brain-surface and atlas visualizations. I kept the steps separate so the media handling, prediction and interpretation can each be examined.

Python · Gradio · TRIBE v2 · Nilearn · Media preparation

From media to an exploratory visualization

1. **Prepare** — Accept video, text or an image and build the model’s input events.
2. **Predict** — Run the pretrained research model to obtain brain-response predictions.
3. **Explore** — Render maps and calculate application-specific summaries.

The implementation separates the research model’s prediction from my visualization and scoring choices.

#### Summarize a large output

A brain map leaves a lot to interpret. I experimented with four manually chosen groups of regions, labelled attention, emotion, memory and reward, to make the output easier to inspect in the interface.

For each group, the scoring function blends 40% mean absolute activation with 60% peak absolute activation, normalizes the result relative to whole-brain statistics and clamps it to a 0–100 display scale. An overall score combines the four groups with weights of 30%, 30%, 20% and 20%, respectively.

| Value | Metric |
| --- | --- |
| 3 | Input paths in the interface |
| 4 | Custom regional groups |
| 0–100 | Application display scale |

> These labels, weights and scales are my exploratory design choices. A score of 80 is not 80% attention, a probability of enjoyment or a scientifically validated “brainrot” classification.

#### What is built, and what remains open

The reviewed code contains the media-preparation paths, pretrained-model integration, visualization helpers and custom scoring logic. It gives me a concrete way to investigate the idea rather than leave it as a hypothetical service.

I have not validated these custom scores against audience attention, enjoyment or retention. They are exploratory summaries of predicted activity, not measurements taken from viewers watching the clip. I have not collected a viewer study or trained a new neuroscience model for this project.

#### The next question: does it help an edit?

The useful next step would be to compare model outputs across controlled versions of the same clip, then test whether any differences agree with independent observations from viewers. That would help separate an interesting visualization from something I could use to make an editing decision.

For now, this project connects two things I enjoy: exploring an unfamiliar technical subject and finding ways it might inform creative work. The open question is part of the experiment.


### Prospecting workspace

> From 1,907 LinkedIn profiles found to a 1,449-profile research workspace, with source context, activity signals and a draft desk that preserves my edits.

Personal project · Research & outreach tooling · October–November 2026

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/8>)

[Français](<https://zaki.somehow.engineer/read/fr/prospecting-workspace.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Research workflow & implementation |
| Initial scope | Hauts-de-France network |
| Core stack | TypeScript · Python · Local UI |
| Period | October–November 2026 |

#### Make prospect research usable

As I began exploring freelance work, prospect research quickly became an information-management problem. Profiles, companies, possible contact details, sources and message drafts all needed to stay connected. I built a workspace that combines browser-assisted research with a local draft queue.

Nine regional keyword searches produced 1,907 distinct profile URLs. The recorded screening added 1,444 profiles with a relevant declared leadership, entrepreneurial or management role. Five existing profiles brought the research workspace to 1,449. The current Airtable count confirms that total; three blank rows are excluded.

| Value | Metric |
| --- | --- |
| 1,907 | Distinct profiles found |
| 1,449 | Profiles in the research workspace |
| 9 | Regional keyword searches |
| 174 | Profile cards in the separate Draft desk |

##### Images and media

[Collection, screening and the retained workspace are separate counts. The final bar includes five existing profiles; 463 collected profiles were not imported. These are research records, not customers.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/research-corpus.en.png>)

Research counts: 1,907 profiles found, 1,444 added after screening, and 1,449 in the workspace including five pre-existing profiles.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/research-corpus.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

#### Keep the evidence with the person

A TypeScript and Node harness works with an authenticated BrowserOS session. It extracts structured information from the observed page and keeps the profile URL, declared role, location, source context and research depth together. Ambiguous or unsupported interfaces return an explicit limitation.

Airtable holds the research records. A company inspection, a website observation and an agent’s interpretation have separate fields. This helps me distinguish something I saw from a possible conversation angle. A name match or a founder title alone does not establish a company identity, purchasing authority or a need for my work.

TypeScript / Node · BrowserOS · Airtable · Python · HTML / CSS / JavaScript

Research that stays connected to its sources

1. **Discover** — Collect declared profile information and preserve its source.
2. **Qualify** — Check the role, company context and depth of the available evidence.
3. **Organize** — Keep activity signals, unresolved questions and next steps distinct.
4. **Prepare** — Use that context for a draft I can review and edit.

Research and preparation workflow. The local Draft desk uses explicit imports; it does not silently synchronize with Airtable.

#### Leave the unknowns visible

The activity map uses explicit French and English phrases in saved professional headlines, with a small set of overrides supported by recorded company notes. In the 27 October snapshot, 522 profiles carry an activity signal and 927 do not have enough evidence for one.

That 36% coverage is useful for choosing where to investigate next. It is not a confidence score or a verified industry classification. The same snapshot has 33 agent-review records, 16 company-inspection notes and 13 recorded websites. Those are different depths of evidence; an agent review can concern a search card rather than a fully inspected profile.

| Value | Metric |
| --- | --- |
| 33 | Profiles with an agent-review record |
| 16 | Profiles with a company-inspection note |
| 13 | Profiles with a recorded website |

##### Images and media

[A deliberately incomplete map: an unsupported category stays unknown. The 27 October analysis supplies these classification counts; the 1,449-profile total and coverage-field counts were checked read-only in Airtable on 10 November.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/classification-coverage.en.png>)

Of 1,449 profiles, 522 have an activity signal, 36.0 percent, and 927 lack sufficient evidence, 64.0 percent.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/classification-coverage.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

#### Use the map to choose a useful question

Software, services, creative work and operational businesses can suggest different conversations. I used the map to form small research cohorts, then look for the actual company, its offer and the context behind the profile before choosing an approach.

The labels overlap. Someone working on software for retailers can carry both software and commerce signals. A financial term can describe a person’s function or a customer market. The chart counts people with signals, not independent companies or confirmed demand.

##### Images and media

[Six of thirteen activity categories from the saved analysis. Counts can overlap and must not be added as a partition. They help choose the next research question, not infer a prospect’s needs.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/activity-signals.en.png>)

Six overlapping profile activity signals: software IT data AI 236, consulting and services 89, marketing media creative 75, property construction 60, health wellbeing 42, and HR recruitment training 39.

[SVG](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/activity-signals.en.svg>)

Credit: Original chart from saved research and import records; aggregate counts only.

#### One person, one shared draft

Draft desk turns the selected contact research into a local review queue. The current local state contains 174 profile cards and 677 candidate contact methods. That is a smaller workspace than the full research corpus, and the contact associations still need checking.

Records are grouped by canonical profile URL. One person has a shared subject and message, several possible contact channels and their own history. Names alone do not merge people, and a shared company inbox does not turn two profiles into one. I can inspect the source context, revise the wording and choose a channel.

From a draft to manual tracking

1. **Review & edit** — Check the association and make the subject and body my own.
2. **Send manually** — Copy the reviewed text into Gmail and decide whether to send it.
3. **Record the channel** — Mark the specific contact method used, then finish or reopen the profile.

Contacted and Done are manual workspace declarations. They are not email-provider delivery receipts.

##### Images and media

[The existing review interface: context, candidate contact methods and a shared draft. This capture uses three fictional profile cards and demo drafts, not the real prospect database.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/draft-desk-context.webp>)

Draft desk overview with a fictional Alex Démo profile, company context and two candidate email options.

Credit: Draft desk’s existing interface, rendered with a local read-only synthetic fixture. All people, companies, contacts and drafts shown are fictional.

#### Keep working while an agent prepares the next batch

An agent can export eligible records and prepare a batch while I keep editing. New drafts append to the queue: the documented example moves a person at 3 / 10 to 3 / 15 without changing their position or draft. Revisions, human-edit flags and completed statuses prevent silent replacement.

A batch is validated as a whole. Reusing the same batch ID with the same content is safe; conflicting reuse or stale revisions are rejected. The local store uses atomic writes and process locks, with migration backups and browser edit recovery when a save fails.

Subject and body edits use a 600 ms autosave delay, and the UI checks for appended work every three seconds. Those are interface settings. The engineering goal is continuity: I can review one message without losing it when the next five arrive.

##### Images and media

[The composer keeps editing and the final decision visible. Read-only synthetic rendering of the existing UI; this capture is not a sent message or a backend persistence test.](<https://zaki.somehow.engineer/content/assets/prospecting/case-study/draft-desk-composer.webp>)

Draft desk message composer showing an explicitly fictional editable subject and email draft with local save status and manual tracking controls.

Credit: Draft desk’s existing interface, rendered with a local read-only synthetic fixture. All people, companies, contacts and drafts shown are fictional.

#### What the project gives me

The recorded Draft desk validation includes 38 Python checks and 59 JavaScript/TypeScript checks, with synthetic UI scenarios for queue continuity, edits, recovery and contact-level tracking. Those figures describe the existing validation record, not a new full test run for this portfolio.

The result is a workspace I can return to: research stays inspectable, drafts stay editable and each person keeps their own context. I have not established a measured reply rate, client-acquisition result or time-saving figure from these records. What I can show is the workflow and the decisions that make it usable.


### Job search abroad

> 3,494 listings across five countries, narrowed into 178 shortlisted postings. A personal search turned into a repeatable data workflow.

Personal project · Search & filtering automation · September 2026

Category: Tools & research

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#built/25>)

[Français](<https://zaki.somehow.engineer/read/fr/job-search-abroad.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Workflow, filtering & review |
| Scope | Five Asian countries |
| Tools | JavaScript · CSV · Apps Script |
| Period | September 2026 |

#### Give a large search a useful shape

For an overseas job search, a familiar title is only the beginning. A data role can hide a working-language requirement, a senior scope or an experience floor that rules it out. I wanted a way to compare the actual requirements against my situation without starting from scratch on every listing.

I worked from scraped LinkedIn exports covering China, Japan, South Korea, Thailand and Vietnam. The saved files contain 3,494 distinct posting IDs. Filtering and review produced 178 shortlisted postings: 75 priority and 103 second tier. That is 5.1% of the collected postings, not an interview or hiring rate.

| Value | Metric |
| --- | --- |
| 3,494 | Distinct source postings |
| 5 | Countries searched |
| 178 | Postings in the final lists |
| 5.1% | Share retained by posting |

#### Start by checking what was actually collected

I kept the original exports separate from candidate pools, rejection files and final lists. Posting IDs make it possible to trace a decision back to its source and keep a later review from being counted as another collected job.

The China archive is a useful example of why that matters. It contains the same 981 IDs as the main export, but preserves 913 descriptions missing there. Matching the files by ID recovers the text without adding a single posting. Across the five countries, 3,301 records have a saved description and 193 still lack one.

##### Images and media

[The size and coverage of the saved dataset. China’s archived descriptions are matched by posting ID. A nonempty description can still be incomplete; these samples do not measure each country’s job market.](<https://zaki.somehow.engineer/content/assets/job-search/case-study/dataset-coverage.en.png>)

Country bars showing 981 China, 1,000 Japan, 350 South Korea, 569 Thailand and 594 Vietnam postings, split into 3,301 available and 193 missing descriptions overall.

[SVG](<https://zaki.somehow.engineer/content/assets/job-search/case-study/dataset-coverage.en.svg>)

Credit: Original chart from my saved September 2026 exports and review files.

#### Screen against a profile, not a job title

The search used an engineering background, Python and JavaScript experience, C1 English and a conservative junior profile. I was open to adjacent roles and learning a new stack, while needing to understand whether an employer could support an international hire.

The workflow separated three questions: can I meet the written requirements, am I a plausible fit for the work, and is the hiring arrangement practical? Language, mandatory experience and graduate-program restrictions were assessed before a closer review of technical and domain fit. An unstated requirement stayed unknown rather than becoming a positive signal.

JavaScript · CSV parsing · Context-sensitive filters · Evidence notes · Google Apps Script

From collected listings to an application list

1. **Collect & preserve** — Keep original fields and posting IDs; distinguish sources from derived files.
2. **Parse & screen** — Clean scraper markup and interpret language, experience and eligibility requirements.
3. **Review & recover** — Read plausible roles, revisit suspicious rejections and inspect missing information.
4. **Prioritize** — Keep reasons, uncertainty and next actions with each retained opportunity.

JavaScript filtering and saved review tables, with AI assistance and human review. This describes the screening workflow, not automated applications.

#### Try to prove the first filter wrong

The most interesting work was in the exceptions. Scraper tokens could swallow the first digit of an experience range. “0–2 years” then looked like a strict two-year minimum. The parsing code preserves the range, distinguishes required from preferred sections and checks what the number actually refers to.

Vocabulary needed the same care. A description mentioning a senior colleague does not necessarily describe a senior vacancy. “Fresh graduates welcome” does not mean that only recent graduates may apply. In Vietnam, revisiting that distinction restored three postings: one priority and two second tier. The review pool grew from 210 to 213 before the deeper review produced its final list.

##### Images and media

[A concrete correction in the saved files: three postings restored to the review pool, all retained in the final lists. The 39 retained postings represent 38 distinct opportunities using the saved opportunity keys.](<https://zaki.somehow.engineer/content/assets/job-search/case-study/vietnam-recovery.en.png>)

Vietnam screening stages: 594 collected postings, 210 first-pass candidates, 213 after correcting the graduate filter, and 39 final shortlisted postings.

[SVG](<https://zaki.somehow.engineer/content/assets/job-search/case-study/vietnam-recovery.en.svg>)

Credit: Original chart from my saved September 2026 exports and review files.

#### Make the shortlist explain its choices

The final lists keep the evidence and the next action beside the role. Priority means the saved review found a credible reason to apply; second tier keeps a possible route visible while flagging a technical, domain or practical gap. South Korea’s Strong and Technical Stretch categories are aligned with those two groups in the chart.

The 178 posting IDs correspond to 175 opportunities after within-country deduplication: 12 in China, 45 in Japan, 4 in South Korea, 76 in Thailand and 38 in Vietnam. Separate posts can point to the same opportunity. The review uses saved opportunity keys where available and company/title matching for the simpler China and Korea lists.

These are September 2026 search results. Collection coverage and review depth differ between countries, and sponsorship or current availability can remain unresolved. The useful output is a reasoned place to start an application, with the remaining questions attached.

##### Images and media

[75 priority postings and 103 second-tier postings. These are saved screening categories, not confirmed eligibility, employer interest or a comparison of national hiring conditions.](<https://zaki.somehow.engineer/content/assets/job-search/case-study/shortlists.en.png>)

Priority and second-tier posting counts: China 8 and 4; Japan 11 and 34; South Korea 2 and 2; Thailand 37 and 41; Vietnam 17 and 22.

[SVG](<https://zaki.somehow.engineer/content/assets/job-search/case-study/shortlists.en.svg>)

Credit: Original chart from my saved September 2026 exports and review files.

#### Keep follow-up connected to the search

A separate Google Apps Script helper handles the next organizational problem: LinkedIn notifications arriving in Gmail. It imports labelled notification emails into a Google Sheet and uses the Gmail message ID to avoid duplicate rows.

The sheet keeps notification metadata, profile and conversation links, plus fields for company, job ID, status and the next action. The configured schedule is every 15 minutes. Where the email contains no actual message text, the script records a notification and leaves the conversation to be opened manually. Replies and applications remain my decision.

#### A personal search became a reusable method

I ended with country-specific lists, reasons I could inspect and a reusable screening prompt for a different candidate profile or dataset. The process includes a second look at both rejected and retained roles, so a convenient rule does not become an unquestioned conclusion.

The result I can show is the organized search itself: thousands of collected postings reduced to a manageable set of leads, with source context and uncertainty preserved. The saved material does not establish how many applications became interviews or offers.


## Experience

### Enka

> A food-delivery app in Montpellier, built around a shared aim: a fairer arrangement for couriers and restaurants.

Co-founder & CTO · September 2024–present

Category: Experience

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#experience/9>)

[Français](<https://zaki.somehow.engineer/read/fr/enka.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Co-founder & CTO |
| Location | Montpellier, France |
| Involved since | September 2024 |
| Product | Android & iOS |

#### Why I joined

Enka started with a friend's idea. I brought the engineering skills to help make it possible, and I shared the aim behind it: giving delivery workers more say over their work and building a fairer arrangement for couriers and restaurants. It connected with why I became an engineer—to be able to build solutions for myself and the people around me.

#### From choosing a meal to receiving it

Enka is available on Android and iOS. Its current offer is food delivery in Montpellier at restaurant takeaway prices, with no restaurant commission. Customers choose a restaurant, build a basket, pay by card or select cash on delivery, and follow preparation and delivery. The app also offers guest ordering and messaging with the courier.

Those screens sit on top of a service involving restaurants, couriers and the team handling day-to-day operations. That connection was the engineering problem I worked on: making the information and actions across the service fit together.

##### Images and media

[The restaurant-price proposition and a restaurant page.](<https://zaki.somehow.engineer/content/assets/enka/enka1.webp>)

Enka promotional screen presenting restaurant prices and a restaurant page.

Credit: Enka app promotional imagery.

[Browsing restaurants and presenting payment options.](<https://zaki.somehow.engineer/content/assets/enka/enka2.webp>)

Enka promotional screen showing restaurant browsing, categories and payment options.

Credit: Enka app promotional imagery.

[Following preparation, delivery and the courier’s position.](<https://zaki.somehow.engineer/content/assets/enka/enka3.webp>)

Enka promotional screen showing order stages, arrival time and courier tracking.

Credit: Enka app promotional imagery.

#### One order, three connected interfaces

As CTO, I worked on the application and its technical foundations: restaurant information, ordering, courier workflows and administration. A customer placing an order, a courier collecting it and an operator resolving an exception all need a consistent view of what is happening.

The application documentation separates these into customer, courier and administrator roles. My work connected the interfaces with their shared data and state changes. The stack includes Next.js/React, Supabase/Postgres and Mapbox.

Next.js / React · Supabase / Postgres · Mapbox

A simplified view of the application’s three roles

1. **Customer** — Browse restaurants, build a basket, place and follow an order.
2. **Courier** — Accept a job, collect the order and update its progress.
3. **Operations** — Maintain restaurant information and handle order exceptions.

Workflow summary based on the application documentation; not a deployment architecture diagram.

#### Make restaurant information usable

Alongside the application, I built tools to collect and compare restaurant menu information. The same dish can have a different name, appear in another section or use a different price format across sources. Collecting pages is only the first part of the problem.

I kept collection separate from matching and comparison. That made it possible to revise section-aware fuzzy matching and inspect the comparison output without repeating the entire collection process. A recorded benchmark covered ten restaurant URLs with different page structures and tracked timing, observed prices and failures. The aim was to understand the limits of the data as well as obtain it.

From source menus to a reviewable comparison

1. **Collect** — Capture menu structure, dish names and prices from each source.
2. **Match** — Compare dishes within their sections and handle naming differences.
3. **Review** — Inspect the comparison and revisit ambiguous matches.

Supporting engineering work documented in UltimateScrapeV1; benchmark sample: ten restaurant URLs.

#### Understand the delivery system around the app

The team’s business plan explores a cargo-bike relay model for Montpellier: collect orders inside the pedestrian centre, transfer them at collection points and let couriers handle the onward delivery. It is useful context for the coordination problem behind the software.

The plan presents an AnyLogic simulation of that approach. It reports faster delivery for 60% of simulated orders, equivalent times for 29% and delays for 11%. Within the delayed group, 5% of all simulated orders were more than five minutes late. The figures show both the potential benefit and the cases that still need attention.

| Value | Metric |
| --- | --- |
| 60% | Faster delivery |
| 29% | Equivalent time |
| 6% | Other delays |
| 5% | Delay over five minutes |

> Historical team simulation, not observed delivery performance. The supplied business plan does not include the full run settings or sample size. Logistics modelling is credited to the Enka project team.

##### Images and media

[Delivery-time outcomes reported by the team’s simulation.](<https://zaki.somehow.engineer/content/assets/enka/case-study/delivery-simulation.png>)

Historical simulation: 60 percent faster, 29 percent equivalent, 6 percent acceptable delay and 5 percent delay over five minutes.

Credit: Enka project team · Enka Business Plan, pp. 22–23. Historical simulation.

[The documented simulation scene on Rue Saint-Guilhem.](<https://zaki.somehow.engineer/content/assets/enka/case-study/montpellier-simulation.jpg>)

Simulation screenshot showing delivery agents along Rue Saint-Guilhem in Montpellier.

Credit: Enka Business Plan, p. 19 · map © OpenStreetMap contributors.

[A modelled emissions comparison included in the logistics study.](<https://zaki.somehow.engineer/content/assets/enka/case-study/emissions-simulation.jpg>)

Historical model plot comparing volatile organic compound emissions with and without cargo bikes over time.

Credit: Enka project team · Enka Business Plan, p. 23. Model output; not measured street emissions.

#### Working with the visual team

I also contributed to application UX/UI and took part in visual discussions: offering ideas, requesting revisions and working through how the application and its presentation should relate. Design was collaborative. Amandine Basset contributed UX/UI work, and Rouge Studio developed identity and communication work.

The studio’s documents explore three directions: interlocking parts, bicycle culture and movement. The movement concept connects the courier, bicycle wheels and the relationships between the people using the service. The strategic dossier carries the same concern into its creative brief: make the people behind a delivery visible while keeping the experience simple.

##### Images and media

[The reasoning behind the movement direction.](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-movement.jpg>)

Rouge Studio’s movement concept connects a courier, bicycle wheels and the relationships within Enka.

Credit: Rouge Studio — Luna Martin, Yasmine Bourhan and Maxine Mulot. Understanding Empathy ENKA, p. 19.

[Identity applications explored through product and delivery-bag mockups.](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-applications.jpg>)

Enka identity proposal applied to a bottle and courier delivery bags.

Credit: Rouge Studio — Luna Martin, Yasmine Bourhan and Maxine Mulot. Understanding Empathy ENKA, p. 23. Concept mockups.

[Communication concepts bringing the courier into the foreground.](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-campaign.jpg>)

Enka communication concepts featuring a courier portrait and branded food bag.

Credit: Rouge Studio — Luna Martin, Yasmine Bourhan and Maxine Mulot. Understanding Empathy ENKA, p. 24. Concept mockups.

#### Where it stands, and what I take from it

The app is publicly available, and the team is working toward the traction needed for its first pre-seed funding. I remain involved, with less day-to-day coding during this phase.

The project expanded the scope of my engineering work. A screen, an order status and a courier's next action all have to make sense together. Building the product meant thinking about those connections and working with people whose expertise went beyond my own.

#### Links

- [Visit Enka](<https://enkalivre.fr/>)
- [Android](<https://play.google.com/store/apps/details?id=com.enka.client>)
- [iOS](<https://apps.apple.com/fr/app/id6803603934>)


### Decathlon

> Exploring how holidays, weather and events can improve sales forecasts through covariate research and feature engineering.

Data Scientist & ML Engineer · March 2024–February 2025

Category: Experience

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#experience/10>)

[Français](<https://zaki.somehow.engineer/read/fr/decathlon.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Data Scientist & ML Engineer |
| Location | Croix / Lille, France |
| Employment period | March 2024–February 2025 |
| Forecast model | Temporal Fusion Transformer |

#### My work at Decathlon

At Decathlon Digital, I worked mainly on forecasting covariates: additional inputs such as public holidays, school vacations, weather and events that might help explain changes in demand. My work involved preparing external data, engineering features and evaluating whether those signals added useful information to sales forecasts.

I started with an internship from March to September 2024, then continued working at Decathlon until February 2025.

The example below comes from my internship report and focuses on calendar variables in an existing Temporal Fusion Transformer forecasting model. The detailed scope of my subsequent work is confidential. The wider forecasting platform was a team effort.

##### Images and media

[Where forecasting sits in the wider supply-chain context.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/planning-context.jpg>)

Company diagram placing planning alongside industrial processes, production, transport, logistics and retail.

Credit: Decathlon · Supply & Material Planning, p. 7. Company context.

#### Build a calendar dataset the model can use

Before training anything, I had to find calendar sources with enough history, future coverage, regional detail and a dependable update process. I compared government data, Date Holidays, Workalendar and Open Holiday API with input from data stewards.

I aligned the selected calendar information with weekly sales data, including the date, holiday name and its position in the week. School-vacation coverage varied across sources, so I began that part of the analysis with France and its three school zones. Preparing comparable data was a substantial part of the work.

Python / Pandas · PySpark · Databricks · MLflow · Nixtla / TFT · Matplotlib / Seaborn

From external dates to forecasting features

1. **Source** — Check date coverage, regional detail, reliability and maintenance.
2. **Align** — Connect calendar dates to the weekly sales index and relevant geography.
3. **Encode** — Represent holiday timing and vacation periods as model inputs.

Summary of the data preparation described in the report, pp. 17–20 and 33–34.

##### Images and media

[The criteria used to evaluate candidate calendar sources.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/source-selection.jpg>)

Presentation slide comparing date range, content, trustworthy sources and maintenance as data-selection criteria.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 17. Original presentation figure.

#### Check the analysis before extending the model

A recurring event can already be partly represented by seasonality. I decomposed the sales series into trend, seasonal and residual components to investigate what additional signal calendar features might offer.

I also had to revisit early findings. An apparent lag before a holiday disappeared after correcting the implementation. I reran the analysis and compared less seasonal products as well as aggregate sales. That correction mattered: an appealing explanation of buying behaviour was not enough to make a feature useful.

##### Images and media

[Separating recurring seasonal structure from the residual variation being investigated.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/decomposition.jpg>)

Presentation showing the observed series, trend, seasonal component and remainder.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 25. Original presentation figure.

[A corrected rerun changed the apparent holiday-lag pattern; the earlier plot is shown for comparison.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/analysis-correction.jpg>)

Old and corrected boxplots for sales around weekday and Saturday holidays.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 29. Original presentation figure.

#### Turn dates into features

I explored holiday flags, long weekends and a countdown to the next holiday. A Day Counter represented how close the holiday’s weekday was to the weekend, using values from 0 to 3. The experiments also considered week/month representations and French school vacations.

The representation itself became an experiment. After team feedback, I compared scalar and one-hot encodings, applied MinMax scaling to the holiday countdown and tested sine/cosine representations of week and month. Different encodings gave the model different ways to use the same calendar information.

##### Images and media

[A compact representation of a holiday’s position relative to the weekend.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/calendar-encoding.jpg>)

Day Counter diagram with values zero on Saturday and Sunday, one on Monday and Friday, two on Tuesday and Thursday, and three on Wednesday.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 32. Original presentation figure.

[The feature combinations compared in the revised experiments.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/feature-combinations.jpg>)

Matrix of experiment variants combining long weekends, holiday countdown and week/month representations.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 41. Original presentation figure.

#### Backtest the idea, then look inside the score

I compared model variants with the existing production-model baseline in offline tests. The report describes a 52-week forecast horizon and five cutoffs: weeks 37 and 47 of 2022, and weeks 5, 15 and 25 of 2023. Using several cutoffs made it possible to inspect performance across different parts of the year.

The first aggregate comparison did not improve on the baseline, while a Top 400 product analysis was more promising. I then refined the encodings and ran another benchmark. The report records training runs of roughly three to four hours, so choosing and documenting each experiment was important.

How the forecasting variants were evaluated

1. **Compare** — Use the same reported reference model and evaluation horizon.
2. **Break down** — Inspect cutoffs, product groups and the Top 400 product subset.
3. **Revise** — Use the findings and team feedback to choose the next feature encoding.

Evaluation workflow from the report, pp. 36–43. Runtime is the report’s approximate per-training-run account.

#### A modest gain, and a change in ranking

The revised global benchmark reported a baseline WAPE of 41.20 and two variants at 40.91 and 40.83. Lower WAPE means lower forecast error in this evaluation. The best displayed global result was approximately 0.37 lower on the reported WAPE scale.

The result did not carry over uniformly. The best global variant was not the best on the Top 400 subset, where a different encoding performed better. That was the useful conclusion: a feature needs to be evaluated with the products and periods it is intended to serve.

| Value | Metric |
| --- | --- |
| 41.20 | Baseline WAPE |
| 40.83 | Best reported global WAPE |
| 0.37 | Lower on the WAPE scale |
| 52 weeks | Forecast horizon |

> Offline evaluation documented in the 2024 report. Displayed scores are rounded to two decimals; the source table shows 41.2016 and 40.8329. These are benchmark results, with no production rollout or business savings established by the report.

##### Images and media

[The revised global benchmark. “Global” refers to the aggregation in this evaluation, not every production series.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/benchmark-global.jpg>)

Global benchmark table showing baseline WAPE 41.2016 and the best displayed variant at 40.8329, evaluated across five cutoffs.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 42. Original presentation figure.

[The same variants on a product subset: the ranking changes.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/benchmark-top400.jpg>)

Top 400 benchmark table showing baseline WAPE 19.2801 and different variant rankings from the global table.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 42. Original presentation figure.

#### Use interpretation to decide what to test next

I inspected model feature importance to understand which inputs the TFT was using. The holiday countdown ranked highly alongside the previous season’s sales. That was a useful diagnostic, while the backtest remained the evidence for forecast quality; an importance score alone does not establish a causal effect.

I documented the work in Confluence, followed the team’s Jira workflow and presented the findings in English to an international team. Feedback directly shaped the next encoding experiments. What I took from the experience was a more disciplined way to build: state the question, check the data and implementation, run the comparison, and explain where the result holds.

##### Images and media

[Inspecting which inputs the model used, alongside the forecast benchmark.](<https://zaki.somehow.engineer/content/assets/decathlon/case-study/feature-importance.jpg>)

TFT feature-importance plot showing days until next holiday and sales quantity last season as the highest-ranked displayed variables.

Credit: Zaki Gouizi · Decathlon internship report, 2024, physical p. 43. Original presentation figure.


### StudentBank

> From student needs to product diagrams, React interfaces and a Node.js/MongoDB backend.

Full-stack JavaScript intern · July–September 2022

Category: Experience

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#experience/11>)

[Français](<https://zaki.somehow.engineer/read/fr/studentbank.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Full-stack JavaScript intern |
| Period | July–September 2022 |
| Frontend | React · Chakra UI · Figma |
| Backend | Node.js · MongoDB |

#### A product built around student life

StudentBank was a student-focused product bringing together financial services, housing and international mobility. During my full-stack JavaScript internship, I worked across user interviews, interface design and development, including the API and authentication.

The interesting part for me was following the same need through different layers: what a student wants to do, what the interface should show, and what the system needs to handle behind it.

##### Images and media

[Three parts of the product, brought together on the desktop homepage. Excerpt; open to see the complete design.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/home-introduction.webp>)

Desktop homepage introducing banking, housing and mobility with three illustrated service panels.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/home-light-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

#### Start with the people using it

I conducted user interviews and translated requirements into UML diagrams. For housing, the journeys involved more than browsing listings: students needed to apply, share documents and follow their requests, while landlords and administrators needed their own actions and responsibilities.

The surviving use-case diagrams make that separation visible. They describe the intended product behaviour and helped make the scope concrete before implementation.

From user needs to product behaviour

1. **Listen** — Collect needs through user interviews.
2. **Map** — Identify actors, actions and the interactions between them.
3. **Specify** — Use diagrams to make feature behaviour explicit.

A summary of my approach, based on the internship account and the original UML documents.

##### Images and media

[Housing from the student’s side: finding an offer, applying, exchanging documents and managing the tenancy.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/student-housing.webp>)

Use-case diagram connecting the student and administrator to housing search, applications, documents and tenancy management.

Credit: StudentBank project archive · original UML export, 2022.

[The other side of the same service: what a landlord can publish, change and follow.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/landlord-housing.webp>)

Landlord and administrator use cases for creating, editing, withdrawing and following a housing listing.

Credit: StudentBank project archive · original UML export, 2022.

#### Give the product a data model

The same work extended to international mobility: choosing a country, exploring schools and courses, submitting an application and tracking the response. I used modeling to connect these journeys to the information the application would need.

The class diagram brings users, files, institutions, housing, leases and applications into one view. This was the bridge between a set of screens and a product with related records, different actors and actions to support.

##### Images and media

[International mobility extends the journey to schools, courses and application tracking.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/international-mobility.webp>)

International mobility diagram with country selection, schools, courses, applications, documents and administrator actions.

Credit: StudentBank project archive · original UML export, 2022.

[A domain model connecting people, documents, places and applications. This is a design artifact, not a database schema export.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/domain-model.webp>)

Class diagram linking users, students, administrators, files, institutions, schools, housing, applications and leases.

Credit: StudentBank project archive · original UML export, 2022.

#### Build interfaces from the prototypes

I worked on Figma prototypes and developed React interfaces with Chakra UI. The archived website separates shared navigation and the footer from page content, with routes for the homepage, application, mission, team and contact pages.

The light and dark designs also carried through into the code: Chakra’s colour-mode hooks switch colours, backgrounds and some image assets. The exports below show the design direction; the surviving MobileTest branch captures only part of its implementation.

React 18 · Chakra UI 2 · React Router 6 · Figma

##### Images and media

[Light version: account information and card presentation. Open for the complete page.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/desktop-light.webp>)

Light desktop design excerpt showing a phone account mockup and bank card presentation.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/home-light-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

[Dark version: corresponding content with alternate surfaces and image assets.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/desktop-dark.webp>)

Dark desktop design excerpt showing the matching phone account mockup and bank cards.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/home-dark-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

#### Adapt the experience to a phone

The mobile design reworks the sequence into a narrow page: compact navigation, a clear introduction, then the individual services. In the source, the navigation has separate desktop and mobile layouts, including a full-screen mobile drawer.

I also worked on separate desktop and mobile layouts for the banking section. The archive preserves that adaptation work in progress rather than a finished record of every screen at every device size.

##### Images and media

[Mobile, part 1: navigation, introduction and cards.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-introduction.webp>)

Top of the mobile design: compact navigation, account preview, introduction and cards.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

[Mobile, part 2: housing and student benefits.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-housing.webp>)

Middle of the mobile design: housing section and student benefits.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

[Mobile, part 3: international mobility and footer. Each excerpt opens the full design.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-international.webp>)

Bottom of the mobile design: international mobility and legal footer.

[SVG](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/mobile-full.webp>)

Credit: StudentBank project archive · supplied interface export, 2022.

#### Connect the interface to the backend

My full-stack work included designing and implementing a REST API in Node.js with MongoDB. I worked on modular code, request and response handling, errors and authentication, so the product work extended beyond what appeared on screen.

Authentication work involved JSON Web Tokens, bcrypt, crypto-js and OAuth 2.0 login integrations. That backend scope comes from my internship account and CV; the public website repository contains the frontend portion of the archive.

Node.js · MongoDB · REST API · JWT · bcrypt · OAuth 2.0

The layers of my full-stack work

1. **Interface** — React components and user-facing interactions.
2. **API** — Node.js routes, requests, responses and error handling.
3. **Data & identity** — MongoDB records and authentication flows.

Overview of my internship responsibilities, rather than a recovered deployment diagram.

#### What this experience gave me

This was an early chance to work across the whole path from a conversation about a need to a modeled feature, an interface and its backend. It helped me understand why those parts have to be developed together.

The remaining materials show the breadth of that work: product diagrams, desktop and mobile designs, and React source code. They are the most useful record I have of this three-month internship.

> The visuals are historical project exports and include placeholder content. They illustrate the intended interfaces, not evidence that all advertised financial services or product features launched.

##### Images and media

[Appointment interface design. The archived branch contains the form UI; a working booking service is not established by this archive.](<https://zaki.somehow.engineer/content/assets/studentbank/case-study/appointment.webp>)

Dark appointment design with date, reason, contact fields and a confirmation button.

Credit: StudentBank project archive · supplied interface export, 2022.

#### Links

- [Source · MobileTest](<https://github.com/zakich4n/StudentBank-website/tree/MobileTest>)


### Engineering studies

> A general engineering education, a computer science specialisation, and the tools to start building my own solutions.

Lille · Preparatory studies & engineering degree · 2018–2023

Category: Experience

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#experience/12>)

[Français](<https://zaki.somehow.engineer/read/fr/engineering-studies.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| Engineering school | JUNIA HEI · 2020–2023 |
| Specialisation | Computer science |
| Preparatory studies | Lycée LaSalle · 2018–2020 |
| Location | Lille, France |

#### Why I chose engineering

I wanted to be able to build solutions myself. When I run into a problem, my first question is often: “Would it be faster to make it myself?” Engineering felt like a way to gain the knowledge and independence to follow that question through.

That is still what connects a lot of my projects: noticing something frustrating, understanding how it works, and trying to make something that fits the way I want to use it.

#### LaSalle · Building the scientific foundation

From 2018 to 2020, I studied in the preparatory programme at Lycée LaSalle in Lille. The curriculum covered mathematics, physics, chemistry and engineering sciences, in preparation for engineering school.

In mathematics, that meant analysis, linear algebra, geometry and probability. Physics brought mechanics, thermodynamics, electromagnetism, optics and waves. Alongside those subjects, engineering sciences introduced mechanical and electronic systems and applied programming. It was a foundation in breaking problems down, reasoning carefully and using models to describe how things work.

#### HEI · General engineering, then computer science

I continued at JUNIA HEI in Lille from 2020 to 2023, earning an engineering degree with a specialisation in computer science. The programme kept a broad engineering base, including mathematics, probability, statistics and modelling, while letting me go deeper into software.

My computer science coursework covered artificial intelligence, the Internet of Things and web development, using languages and tools including Python, JavaScript and web frameworks. It connected data collection and processing with algorithms and applications: understanding the problem, then having a way to implement an idea.

Mathematics & statistics · Modelling · Python · JavaScript · Artificial intelligence · IoT · Web development

#### Learning to work beyond the code

The degree also included project management, leadership and decision-making, as well as the ethical and societal implications of technology. That broader side matters to me: a technical solution has to make sense for the people who will use it and the people building it together.

I like moving between those perspectives. I can enjoy understanding an algorithm, working through an interface, or discussing what a product should actually do. The general engineering background gave me room to develop across those areas.

#### Putting it into practice

During my studies, I joined StudentBank as a full-stack JavaScript intern from July to September 2022. I worked from user interviews and UML diagrams through React interfaces and backend development. It was a chance to follow a product need across several layers of an application.

Later, that background took me towards forecasting at Decathlon and building Enka’s technical foundation. Those experiences have their own pages here; they show where I took the tools I started developing at school.

#### Related work

- [StudentBank · Full-stack internship](<https://zaki.somehow.engineer/read/en/studentbank.md>)
- [Decathlon · Forecasting](<https://zaki.somehow.engineer/read/en/decathlon.md>)
- [Enka · Building a platform](<https://zaki.somehow.engineer/read/en/enka.md>)


## Creative work

### Making films with friends

> Camera work on my phone, ideas for a scene and helping friends bring their projects to life.

Film · Creative collaboration

Category: Creative work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#art/13>)

[Français](<https://zaki.somehow.engineer/read/fr/filmmaking.md>)

#### Finding my place on a shoot

On a film with a friend, I operated the camera on my phone and contributed ideas about where people should stand and how to frame the scene. He had written the script and took care of the edit.

I enjoy working with people who know their craft. When an idea I bring helps a scene, it gives me confidence in what I can contribute. Film is also a way to express how I see things and make something I’m excited to show friends and family.

#### Music videos with Tatsumi

Tatsumi is a friend who makes rap. I helped out on two of his music videos, 1er AOÛT and SALE HIVER. Both include me in their thanks credits.

##### Images and media

[TATSUMI — 1er AOÛT](<https://www.youtube.com/watch?v=fnPCnR6Q85o>)

Official thumbnail for Tatsumi’s 1er AOÛT music video.

Released in August 2025. My contribution is acknowledged in the thanks credits.

Credit: Tatsumi · Camera: kotoblade & giola. Edit: kotoblade & coton. Colour: kotoblade.

[TATSUMI — SALE HIVER](<https://www.youtube.com/watch?v=zZhRBmiOj4I>)

Official thumbnail for Tatsumi’s SALE HIVER music video.

Released in August 2025. My contribution is acknowledged in the thanks credits.

Credit: Tatsumi · Camera: kotoblade & giola. Edit: kotoblade & coton. Produced by Planar Films.

#### Around the camera

The finished clip is only one part of a shoot. Coton Production’s making-of follows the work around the videos, and Tatsumi’s reel gives another glimpse of the project.

##### Images and media

[COMMENT on a tourné 5 CLIPS en 4 jours (Ep 1)](<https://www.youtube.com/watch?v=o8klq8y6okE>)

Official thumbnail for Coton Production’s making-of.

A making-of shared by Coton Production, linked from the SALE HIVER shoot.

Credit: COTON PRODUCTION · Filmed by COTON.

[Tatsumi — 23](<https://www.instagram.com/reel/DMspX5OM62_/>)

Official portrait preview of Tatsumi’s Instagram reel.

A short reel shared by Tatsumi around the release of 23.

Credit: @23.tatsumi · Clips credited to kotoblade, coton.production, aloigiola and planar.films.

#### More from the shoots

I also have short clips and photographs from shoots, including an Enka trailer. These spaces keep their original proportions while I arrange hosting for the files.

- Not yet published: Landscape footage 01 · hosting to come.
- Not yet published: Landscape footage 02 · hosting to come.
- Not yet published: Portrait footage 01 · hosting to come.
- Not yet published: Portrait footage 02 · hosting to come.
- Not yet published: Portrait footage 03 · hosting to come.
- Not yet published: Enka trailer · hosting to come.
- Not yet published: Landscape still · visual to come.
- Not yet published: Portrait photograph · visual to come.


### Cooking

> About two years of learning to cook, from desserts to savoury meals. Mediterranean and Chinese food are my favourites, especially Kung Pao.

Personal creative practice

Category: Creative work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#art/14>)

[Français](<https://zaki.somehow.engineer/read/fr/cooking.md>)

#### A practical beginning

I started taking cooking seriously about two years ago, when I was living on my own on a tight budget. I wanted to eat well and make my money go further than it would eating out.

I began with sweet dishes and desserts, then gradually made my way into savoury cooking. The photos here are a few things I’ve made along the way.

##### Images and media

[Chocolate tart.](<https://zaki.somehow.engineer/content/assets/cooking/chocolate-tart.webp>)

A homemade chocolate tart with a slice cut out.

Credit: From my cooking archive.

[Strawberry tart.](<https://zaki.somehow.engineer/content/assets/cooking/strawberry-tart.webp>)

A homemade strawberry tart on a plate.

Credit: From my cooking archive.

#### Follow the recipe, then make adjustments

For the first year, I followed recipes closely to learn the basics. Now that I understand a little more, I’m more comfortable adapting them.

When I try something new, I still prefer to stay close to the recipe. I like having that starting point before deciding what to change.

##### Images and media

[Cinnamon rolls, before baking.](<https://zaki.somehow.engineer/content/assets/cooking/cinnamon-rolls.webp>)

Shaped cinnamon rolls in a baking dish before baking.

Credit: From my cooking archive.

[Chocolate cookies with white chocolate pieces.](<https://zaki.somehow.engineer/content/assets/cooking/chocolate-cookies.webp>)

Homemade chocolate cookies with white chocolate pieces on baking paper.

Credit: From my cooking archive.

[Speculoos cheesecake. A short clip from my cooking archive, with its original on-screen caption.](<https://zaki.somehow.engineer/content/assets/cooking/speculoos-cheesecake.mp4>)

A short personal clip of a slice of homemade speculoos cheesecake.

Credit: Personal cooking video · 1.83 seconds · silent.

#### From sweet to savoury

Mediterranean and Chinese food are the cuisines I’m most drawn to. As I moved beyond desserts, savoury meals became another part of what I enjoy making.

##### Images and media

[Turkey, potato wedges and ratatouille, with a bowl of pumpkin couscous.](<https://zaki.somehow.engineer/content/assets/cooking/savoury-meal.webp>)

A plate of turkey, potato wedges and ratatouille beside a bowl of pumpkin couscous.

Credit: From my cooking archive.

#### Kung Pao, with the roasted peanuts

My favourite dish of all is Kung Pao. I remember a generous plate for about €2 during my first trip to China with Recto Verso. The balance of sweet, salty and umami was so good that the meal stayed with me.

It’s one of my favourite things to make at home too. The roasted peanuts are non-negotiable: without them, I’d rather make something else.


### Learning to make clothes

> From shortening trousers to trying to make pieces of my own: an Enka delivery-bag cover prototype, black trousers waiting to be sewn and a jacket planned next.

Sewing · Learning in progress

Category: Creative work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#art/15>)

[Français](<https://zaki.somehow.engineer/read/fr/clothes.md>)

#### Start with making things fit

I’ve always liked fashion, but money and confidence often kept me from wearing the more distinctive pieces I liked. Trousers also often needed shortening, so I used to take my clothes for alterations.

That became expensive too. I started shortening my trousers myself a long time ago and have since adjusted larger clothes to fit. In April 2026, I decided to try making complete garments of my own.

#### A cover for Enka’s delivery bags

I made a basic prototype cover for existing Deliveroo and Uber Eats delivery backpacks, using Enka’s colours and name. It gives the bag an Enka identity without replacing the bag itself.

Rayan, Enka’s CEO, uses this prototype on his daily deliveries. We’d like to make covers for the whole delivery team as Enka grows. For now, it remains a prototype in everyday use.

##### Images and media

[Fitting and securing the Enka prototype cover over an existing delivery backpack.](<https://zaki.somehow.engineer/content/assets/clothes/enka-bag-cover.mp4>)

A red Enka cover being fitted over an existing delivery backpack, fastened and worn.

Credit: User-supplied Enka prototype video · short silent clip.

#### Another pair, with my own details

My current project is another version of a pair of black tri-fold trousers I bought in China. I haven’t been able to find the brand online. I want to add two extra pockets and some design details of my own.

The plan includes silver-coloured snap details at the folds, with engraving. Sewing is still ahead of me. The images below are references for the silhouette and hardware I have in mind.

##### Images and media

[A representative pleated silhouette. This is a style reference; my own pair was bought in China and the version I want to make is black.](<https://zaki.somehow.engineer/content/assets/clothes/pleated-trouser-reference.webp>)

External Beaulares product photograph showing dark grey wide pleated trousers on a model.

Credit: [Beaulares · SILVANO TROUSER, GRAY. External product image.](<https://beaulares.com/collections/bottoms/products/tri-fold-trouser-2-0>)

[External hardware inspiration for the planned trouser details. Product reference from A&A.](<https://zaki.somehow.engineer/content/assets/clothes/metal-fastener-reference.webp>)

External product reference showing different round metal snap-fastener finishes and their components.

Credit: [A&A · Metal snap-fastener reference supplied by Zaki. Original product image.](<https://www.a-et-a.com/media/catalog/product/q/u/qupre0p390aaa-2.jpg>)

#### Keep learning, one piece at a time

IT projects and life have put the sewing on hold. When I start, I’d like to set aside two or three days in one stretch so I can stay with the piece and avoid losing track.

A jacket is the next piece I’d like to try after the trousers. This is still early work, and I see myself continuing occasionally, making room for it alongside my other projects.


### Recto Verso

> Art, photography and visual projects, shared with a creative collective.

Association · Co-president with Luna Martin · Since 2025

Category: Creative work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#art/24>)

[Français](<https://zaki.somehow.engineer/read/fr/recto-verso.md>)

#### At a glance

| Metric | Value |
| --- | --- |
| My role | Co-president |
| Since | 2025 |
| Alongside | Luna Martin |
| Focus | Art · Photography · Visuals |

#### An association for art and visual work

Since 2025, I’ve been co-president of Recto Verso alongside Luna Martin. It’s an association for art, photography and visual projects, and another way for me to work with creative people beyond software.

Luna is also one of the creatives I worked alongside on Enka’s visual direction. Recto Verso gives that shared interest in images and art a space of its own.

##### Images and media

[Recto Verso’s visual identity.](<https://zaki.somehow.engineer/content/assets/recto-verso/logo-with-text.png>)

Recto Verso logo: two interlocking geometric forms in black, white and grey, with the association name above and below.

Credit: Recto Verso · supplied association logo.

#### A shared interest in different ways of creating

The association has brought together different people over time. My place in it is as a co-president and participant, with an interest in contributing ideas and learning from people with their own creative practices.

#### A trip to China

We travelled to China through Recto Verso. The mission brief focused on exploring traditional and contemporary design practices and encountering approaches different from those taught in France.

Led by Luna, the proposed mission named Beijing, Xianyang and Shanghai. It set out photography, video, sketches and interviews as ways to document the research, alongside possible studio visits and workshops. These describe the plan behind the trip; the materials here don’t document each activity as completed.

#### Where we are now

We haven’t yet had the work published or held an exhibition. The group has changed as people have joined and left, but the China trip is a concrete part of what we’ve done together.

For me, Recto Verso belongs here because creative collaboration is part of my life too: working on images, sharing ideas and exploring something with other people.


## Beyond work

### Games

> From Pokémon on a Game Boy Advance to RPGs, with a PSP somewhere along the way.

Games · Handhelds, PC and RPGs

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/16>)

[Français](<https://zaki.somehow.engineer/read/fr/games.md>)

#### Growing up with a console in hand

My first console was a Game Boy Advance. I played Pokémon and Yoshi’s Island, then spent time with a Nintendo DS and a PSP—the reference behind this portfolio. Later came the PS2 and Xbox 360.

There was also the family computer. I played Minecraft and spent a lot of time online in Dofus, before moving on to League of Legends.

#### Different games at different times

I used to be drawn to action games: Assassin’s Creed and Call of Duty, as well as racing games like Need for Speed: Underground 2 and Most Wanted.

#### Finally playing the kind of world I used to watch

Before I could play RPGs like Skyrim myself, I watched other people play them. I spent a lot of time following Bob Lennon’s Skyrim playthrough, getting caught up in the world and its stories.

Divinity: Original Sin 2 was the first game of that kind I had the chance to play myself. I loved how much lore there was to get into. After spending so long watching those worlds through someone else’s screen, I finally had one to explore for myself. Baldur’s Gate 3 is next, when I can make time for it.

#### Why Breath of the Wild stayed with me

Open worlds can lose me when I keep having to ask what to do next or look up a guide. Breath of the Wild was different. I could follow my curiosity and keep finding my own way forward.

The music, the atmosphere and the care in the details kept me coming back. Combat challenged me without making me want to give up. Everything fitted together so well that I could just enjoy being there.

#### Still coming back

I still play League of Legends a few times a year. The strategy keeps me interested, and it is also what led me to follow esports.


### Esports

> Following Karmine Corp from its early days, and watching League of Legends for the moments that give me goosebumps.

Esports · League of Legends

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/17>)

[Français](<https://zaki.somehow.engineer/read/fr/esports.md>)

#### Following Karmine Corp

I got into League of Legends esports around Karmine Corp’s beginnings. I already followed Kameto and Prime on YouTube and Twitch, and I was playing League myself. Supporting their team felt natural.

Watching those early European Masters wins and the excitement around the team got me hooked. I still support KC today.

#### What I enjoy watching

Alongside KC, I enjoy watching T1, especially players like Zeus and Keria. I like the precision of the play: the individual decisions, the coordination and the way a team moves around the map.

#### T1–Gen.G, Worlds 2024

The 2024 Worlds semifinal against Gen.G is a match I still think about. T1 won 3–1, but the fourth game had a real swing: Gen.G wiped out T1 and closed the gold gap before T1 recovered to finish the series.

Zeus played Gragas, Maokai and Jax across the series. Keria moved from Renata Glasc and Braum to Pyke in the deciding game. Zeus’s double kill on Jax helped build T1’s lead, while Keria’s Pyke brought a much more aggressive support pick into that last game.

That’s what I enjoy watching: players who can bring different things to a team, and a match that stays tense even after one side gets ahead. This one gave me goosebumps.

#### A spectator who also plays

I have never competed in esports. My highest ranked level in League was Gold. I might try for Diamond one day, but for now I’m happy following the scene and playing occasionally.

#### Links

- [T1–Gen.G · Game 4 highlights](<https://www.youtube.com/watch?v=yLj0KQFJTY0>)


### Anime

> Comics and manga first, then Death Note showed me what an animated story could make me feel.

Anime · Stories and new worlds

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/26>)

[Français](<https://zaki.somehow.engineer/read/fr/anime.md>)

#### From manga to watching a story in order

Growing up, reading mostly meant school to me. I preferred comics and manga. I also caught Naruto on television, but the episodes were out of order, which made the story hard to follow.

Finding anime online changed that. I could start at the beginning and actually follow a story from one episode to the next.

#### Death Note was the turning point

Death Note blew me away. I hadn’t expected an animated series to draw me in like that: the storytelling, the music, the tension and the emotions.

Until then, my references for animation were mostly films like Toy Story and cartoons like SpongeBob. Death Note showed me another side of what animation could do, and anime became a big part of what I watched.

#### Five favourites

My top five are Hunter × Hunter, Jujutsu Kaisen, Frieren: Beyond Journey’s End, JoJo’s Bizarre Adventure and Attack on Titan.

#### Giving Haikyu!! a chance

I didn’t think sports anime were for me. Then the friend who introduced me to volleyball at Decathlon recommended Haikyu!!.

I gave it a chance, and it became my favourite sports anime. It made me want to play even more, at a time when we were starting to meet up for volleyball outside work too.


### Volleyball

> A lunch-break invitation at Decathlon became a sport I kept playing in Lille and Montpellier.

Volleyball · From lunch breaks to a team

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/18>)

[Français](<https://zaki.somehow.engineer/read/fr/volleyball.md>)

#### It started at lunchtime

At Decathlon, the lunch break often left room for an hour of sport before eating. A couple of months after I joined, a friend on the same floor invited me to play volleyball with his colleagues. It was my first time, and I really liked it.

For the rest of my time there, I played once or twice a week. That same friend recommended Haikyu!!, which made me even more excited to play. We bought a net setup and started meeting friends to play on the grass over the summer.

#### Taking it to Montpellier

When I moved to Montpellier for Enka, I kept playing. There were club sessions, and we also put together our own team: Les Bouftous, named after the Bouftou from Dofus. Between the two, I was playing about twice a week.

The team brought a more competitive side to it. We had a good run until an ankle injury and another teammate moving to Paris made it difficult to carry on.

#### Receiving, and finding another way to attack

In matches, I mainly focused on receiving. I’m not the tallest player or the biggest jumper, so when I attack, I try to place the ball somewhere people aren’t expecting rather than hit it as hard as possible.

#### Finding my way back to it

I’m not playing at the moment. Work and other things have taken priority, but I want to find somewhere to play again. It’s a sport I really enjoy, and I’d like to make room for it.


### The gym

> After several combat sports, I found a routine I could fit around my own schedule. Now I’m working on consistency and strength.

Training · Consistency and strength

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/19>)

[Français](<https://zaki.somehow.engineer/read/fr/gym.md>)

#### From combat sports to the gym

Growing up, I did two years of taekwondo, a year of kung fu and two years of MMA. After a break from combat sports, I wanted a way to stay in shape again.

I started going to the gym after my baccalauréat, when several friends were getting into it too. I liked being able to go when it suited me, without a fixed class time.

#### Making it a habit

For a long time, I would train for two or three months and then stop for another few months. Over roughly the past year, I have been much more consistent. Now I want to keep that rhythm and build strength.

#### What I’m working towards

I’d like to do a pull-up with an extra 30 kg, five muscle-ups, a 100 kg bench press and a 150 kg squat. Those are goals I’m working towards.

Beyond that, I’d be happy training to maintain what I’ve built. I would also like to return to combat sports one day.


### What’s next

> Freelance work and Enka, time abroad, and more room to make things with the people around me.

Plans · Work, travel and making things

Category: Beyond work

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#life/20>)

[Français](<https://zaki.somehow.engineer/read/fr/whats-next.md>)

#### For now

I am focusing on freelance work and developing a consulting activity with friends. My main focus is AI and automation, while we work together across our specialties.

I remain involved with Enka and would like to return to a more active role as funding progresses.

Alongside this, I’m looking for job opportunities in Paris and abroad.

#### Spend time abroad

I’d love to spend six months or longer living abroad, especially in China. My trips there made me want to experience more of the country beyond a visit. Japan, Korea, Vietnam and Thailand also interest me.

#### Make things for people I know

One day, I’d like to have my own clothing label. I want to make pieces I love wearing and be able to say I made them when someone asks where they came from.

I’d also like to make special pieces for friends and family—including Tatsumi and other friends who put their work out into the world. Being the person they come to for clothes is an idea I really like.

#### Make a short film

I’d like to get better at making films and eventually make a short film or two. Entering the Nikon Film Festival, and perhaps winning a prize, is something I’d love to try one day.

#### Leave room for more

I want to see more of the world and try more things. When I look back, I’d like to have had a life with a lot in it, even if everything I tried didn’t turn into a success.


## Contact

### Let’s talk

> A project, a collaboration, or a question about something I have made—send me a message.

zakigouizi@gmail.com

Category: Contact

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#contact/21>)

[Français](<https://zaki.somehow.engineer/read/fr/email.md>)

#### A direct conversation

Email is a straightforward way to discuss an idea or freelance work. I am open to hearing what you have in mind.

#### Links

- [Email me](<mailto:zakigouizi@gmail.com>)


### Find me on LinkedIn

> Connect with me and keep in touch.

Zaki Gouizi

Category: Contact

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#contact/22>)

[Français](<https://zaki.somehow.engineer/read/fr/linkedin.md>)

#### Professional connections

You can find me on LinkedIn for professional conversations and connections.

#### Links

- [Open LinkedIn](<https://www.linkedin.com/in/zaki-gouizi/>)


### Explore my GitHub

> Browse the public side of my projects and experiments.

@zakich4n

Category: Contact

[Open in the interactive portfolio](<https://zaki.somehow.engineer/#contact/23>)

[Français](<https://zaki.somehow.engineer/read/fr/github.md>)

#### Code and experiments

My public repositories include personal tools and experiments, alongside forks of existing projects. The portfolio explains the context and my contribution to selected work.

#### Links

- [Open GitHub](<https://github.com/zakich4n>)
