That question became ChromeGPT, a local-first Chrome extension that hooks into form fields on any page, classifies their intent from labels, placeholders, and metadata, and generates a suggestion through a locally running Ollama model. Nothing leaves your machine until you click approve.

How it started

The original seed was pure practicality. Job hunting involves filling the same fields over and over: professional summary, years of role specific experience, why do you want to work here. The content changes per application, but the cognitive load of writing it fresh each time is real. I wanted a tool that understood the context of a field, not just a clipboard manager.

The architecture was straightforward to sketch: a content script to inspect the DOM and extract field metadata, a background service worker to route requests, and a local Ollama instance as the brain. Store a RAG context blob in chrome.storage.local — your CV, your bio, whatever grounding material you want — and let the model use it to generate suggestions that actually sound like you.

“The hardest part of any Chrome extension isn’t the LLM integration. It’s the browser security model, and it will humble you every single time.”

The timeline

Phase 1: Concept

Proof of concept with Ollama. Got a bare content script detecting input fields, classifying them by label text, and firing off completions to a local llama3.2 instance. The 403 Forbidden wall from Ollama’s CORS defaults hit immediately — Ollama rejects extension origins unless you start it with OLLAMA_ORIGINS=’chrome-extension://*’. First real friction point.

Phase 2: Dev tooling

Tried Continue.dev with a local Ollama backend as the coding assistant. The appeal was obvious: keep everything local, no token costs, full privacy. In practice, the model response latency on a typical laptop turned development into a patience exercise. Tab completion that takes four seconds isn’t tab completion. It’s just a slow interrupt.

The Pivot: Toolchain change

Switched the dev workflow to OpenAI Codex. The local-model-for-local-product purist argument is compelling right up until you’re waiting forty-five seconds for an autocomplete on a manifest field. Codex cut iteration time drastically. There’s a certain irony in building a local AI tool while using a cloud AI to build it, but pragmatism won. The product stays local; the build environment doesn’t have to.

Phase 3: Field logic

Built the field classifier. The extension reads labels, name attributes, placeholder text, and ARIA metadata, then maps the combination to an intent category: cover letter, professional summary, CRM note, support reply, and so on. The classifier feeds the prompt template so the model knows it’s writing a cover letter, not a support ticket.

Phase 4: UX & safety

Added the approval gate. Generated text is never inserted without confirmation. Right-click context menu triggers generation; the user reviews; only then does it land in the field. This was non-negotiable — an AI that writes into your forms silently is a liability, not a feature.

Phase 5: Shipped

Added the chat page and configuration UI. Beyond form filling, a direct chat interface lets you converse with whichever Ollama model you’ve configured. Settings page exposes the host URL and model name — swap from llama3.2 to mistral or any other installed model in seconds.

The Continue.dev + Ollama lesson

The detour through Continue.dev with a local Ollama backend deserves an honest postmortem, because a lot of developers are drawn to that setup for the same reasons I was: privacy, no recurring cost, and the satisfying consistency of using local AI for everything.

What I found in practice was that the hardware ceiling matters enormously. A quantised 7B model on a mid-range MacBook is workable for one-shot queries. It is not workable as a continuous coding companion where you need suggestions in under a second to stay in flow. Every time the spinner appeared, I’d lose the thread. The context switching overhead of waiting was larger than just typing the code myself.

Switching to Codex didn’t feel like giving up on the local-first principle — it felt like recognising that the principle applies to the user’s data (form content, CV, personal grounding material), not necessarily to the developer’s tooling. The extension itself still sends nothing to the cloud. The development workflow is a different question entirely.

What you can actually do with it

The obvious use case is the one that motivated the project, but once you have a browser extension that understands form fields and has your personal context loaded, a surprising number of tasks become frictionless.

Job applications

Load your CV as RAG context. Open any application form. Right-click the cover letter field, approve the draft. The model knows your background and adapts the tone to the field’s intent.

Profile completions

LinkedIn summary, GitHub bio, Upwork profile, consultant directories. Fields that ask you to describe yourself in 200 words for the eleventh time this month.

Support & CRM replies

The classifier recognises CRM note and support ticket fields. Draft a professional response, edit it, send. Particularly useful for repetitive first-response templates.

Typed search prompts

On search fields where you’re constructing a complex query, type a rough intent and let the model suggest a more precise formulation before you submit.

For job hunting specifically, the workflow looks like this: paste your CV text into the RAG data panel once, then on any application page, right-click the cover letter textarea and generate. The output will reference your actual experience because the model has it as context. You still review, edit for tone, and approve the extension is a drafting accelerant, not an autopilot.

“The best AI tools are the ones where you’re still the author. The extension generates a draft; you decide whether it’s good enough to exist in the world.”

What’s still rough

The roadmap is honest: CV and PDF upload parsing isn’t implemented yet, which means loading your context is a paste operation rather than a file drop. The inline suggestion UI is currently a browser confirmation dialog functional, not beautiful. React and Vue controlled inputs occasionally swallow injected text because they manage their own state, and the extension doesn’t always win that fight.

These are solvable problems. The harder constraint is the Ollama origin configuration requirement users need to start Ollama with a specific environment variable, which is a setup step that will stop some people cold before they ever see a generated suggestion. Smoothing that onboarding path is the highest-priority UX improvement.

Where this goes

The core thesis that your browser should be able to help you fill in fields using context you’ve provided, running entirely locally hasn’t changed. What I’ve learned is that local AI as a product experience is absolutely viable. Local AI as a development environment depends heavily on your hardware and your patience threshold.

If you want to try it, clone the repo, load the ChromeGPT folder as an unpacked extension, start Ollama with the right origin flag, paste some text into the RAG panel, and open a form. Right-click any text field. The rest should be obvious.

The biggest value in low-code tools is the possibility to create value-adding apps fast. In corporate environment lots of legacy tools either miss some key features or the licensing for a useful part of the suite is prohibitively expensive. Building a small widget with simple functionality that may or may not interface with legacy system can fulfill the requirements perfectly. Sometimes the app can be a proof of concept and act as a stepping stone for building a full-flexed application.

In all low-code development tools the process is more or less the same. You first create a data model, then create user interfaces based on the data model and then create the application logic to ensure your app tests successfully against original use cases. How easily all of that happens depends on the tool and the use cases required by the business process you are trying to implement. Mendix has some distinct advantages, but there are also some limitations.

In Mendix you can store the data model into an inbuilt database. Bringing in the model is easiest if you have existing data in an Excel spreadsheet. You can of course design the data model manually as well in the modeling tool, but the downside with this approach is that making changes to the pre-populated content is harder as you need to also create the data management tools yourself. The wizard would have created all of those automatically. Comparing to AppSheeet with Google Sheets integration this is bit more complicated.

The next step after defining the data model is to choose the appropriate page hierarchy. Typically you will have input interfaces for interacting with the data as well as reporting functionality. Populating the input forms with dependency entities helps with creating drop-down menus with dynamic content. More advanced logic is needed to pre-populate things like data from user settings table. The logic starts to get much more complex when there are user profiles and different requirements for what can be shown or allowed for each authenticated user.

I don’t want to get too deep in details in this blog post so let’s just conclude that there are limitations to Mendix, just like to other low-code tools. You can find ways to get around those limitations either by data structure changes, rethinking UI or reconfiguring application logic. To understand how to do this requires a highly specialized skillset for a specific tool and demand for such talented low-code developers is high. It is also good for the customer to understand that there needs to be willingness to compromise on the feature set and sometimes key scenarios actually need development of external APIs.

The first thing to solve is to figure out the best placement for the camera. I assume the best location would be in the middle of the rink although that means there is a stereo video dead spot at the red line. It is not easy to arrange hanging the camera from the ceiling and there are nets on both ends. With a traditional camera it has been difficult to catch action on the nearside so hanging the camera on a long selfie stick on top of the rink would probably be a good option. We will need to try and see what works best.

Publishing the video content in 3d like it is of course possible, but viewing the 3x15min content with a VR headset is way too tiring for the eyes. So the answer really is to find ways of reframing the 360 equirectangular video to plain HD video in post-production. Some of the editors have motion detection plugins for overcapture, but we would also need a way to mask the areas outside of the playing area. Another option could be to crowd-source the panning to people watching on a VR headset. That would require a way to record the head movement data in the video player and server to average from multiple viewers.

First of all it is good to understand some terminology. The UI is not very intuitive so I was bit lost at first.

• Hashcut is part of a Youtube video you would like to publish
• Recording: A Hashcut with multiple parts of the same Youtube video combined
• Mashup: A combination of multiple Hashcuts into one

So to make a highlight reel I will need to review each game video into a recording and then join the hashcuts into one big Mashup joining multiple games. The process is bit more complicated as the games have been published in three parts ie. one for each period of the game. My son plays only part of the time during his own shifts so there is quite a bit of reeling back and forth to find when he is playing and choosing the best parts.

There are some limitations and problems at the moment. There is no way to save the recording once you have finished skimming through the video. The UI is bit buggy and loading the mashups takes quite a bit of time as the player apparently loads all the different youtube clips first before it starts playing. I haven’t gotten the Mashup editor to work as I just get one video to my Mashup for some reason. What I would really like is to be able to be able to export the playlist and maybe capture it to hard copy using VLC.

Anyways I hope the developers continue the development and I can finally share my proudest hockey dad moments.

I recently created a small custom app for tracking hours in the outdoor ice-skating challenge using AppSheet. Now the time is up and the feedback from the beta test gathered. Overall the app accomplished what I set out to do. There were few niggles and I would like to point those out.

• The way I had set out the table in Google Sheets I could not figure out a way to calculate the number of times on ice. Consequently average session lenght was impossible to calculate.
• The chosen bar chart did not show the event in a time line, but just as horizontal bars. A stacked area diagram woud have been a better visualization of how the hours acrued, but no such thing was available.
• There was no way to set a diagonal line in the bar chart to show the current state of the moving goal.
• It was not possible to create a drop-down list in the application settings. I would have liked for the user to be able to select their goal (bronze, silver, gold) and track their performance against it.
• The AppSheet app had to be downloaded by the user and Google user account was required for login. Some users would have liked to have an offline version that can be downloaded from an AppStore (premium feature).
• To access table data AppSheet required rights to a Google Drive. Now in hindsight I would have setup a separate google account just for the app.

In general the app was easy to use and adding the hours was very simple. It was fun to see how many hours other users had accumulated and what is most important my son did reach the gold level in the challenge.

The only downside was that inputting the numbers into the table was bit of a hazzle. So for this winter I built an app using AppSheet.com MADP/aPaaaS. It took couple of evenings of tinkering, but now I have a simple app I can use to insert hours and compare my results with others in the team as well as with the the moving gold medal goal. There is still work to be done on the UI, but I’m quite happy how it turned out. It took pretty minimal effort and does the thing it was meant to.

The app works both on Android and iOS and if you want to give it a try leave your gmail address in the comments and I will send you an invite.

Bitwise  using Hikvision cameras and bluetooth tokens to do some cool analysis of ice hockey games using Quuppa’s platform.

• Offense
  • Goals scored (-10s from end)
  • Offsides (-5s from end)
  • Starts (10s from beginning)
• Defense
  • Goals allowed or goalie saves (-10s from end)
  • Offsides (-10s from end)
  • Starts (10s from beginning)

With this rudimentary classing we will miss shots not on goal and good defense. The boys are just starting out on full ice so there are lot of stoppages to play and even the longest clips are just 3 minutes long. Some additional skimming needs to be done to recognize good performances both in offense or defense. For that a special “highlight” button on the camera would be great.

For sharing the material with the whole coaching team I have uploaded the clips to Youtube. Now the question is how should I annotate the material. I have created a playlist to play all the clips after each other. It would be nice to be able to create alternative playlist with just the offsides, just the goalie saves, just the goals against our team. To easily create that I would need a player with four buttons that mark down the clip and create a timestamp with corresponding tag (#goal, #offsides, # setback, #save).

PS. Additional features such as marking the line ie. players on ice would be nice.

Since 2002 the market has followed the global mega trends also in Finland. Television show type services such as cable-tv and IPTV have been slowly, but surely losing customers to likes of Netflix. After initial surge pay-tv operators’ profits have started to decline. Only real-time sports is driving the market. Local broadcasters’ (Nelonen, MTV3) online offerings have matured, but the commercial model is unclear. New players like Veikkaus (gambling) have entered the market offering game streams for free.

The biggest winner has been user-generated content. Succesfull vloggers have gained celebrity status and draw huge numbers of viewers. You might even argue that it isn’t user-generated content anymore. Publishing houses (eg. magazines) are venturing out to do weekly or even daily shows that pamper their chosen audiences with new content on regular intervals. The automated sports services have not really gained market-share, but artificial intelligence could change that in the next ten years.

To understand better what will happen next additional analysis is needed. The methodology selected for the original study, PARTS-analysis introduced in Adam Brandenburger’s ja Barry Nalebuff’s book Co-opetition, will serve us well for this analysis also. In the following posts the five different aspects (Players, Added Values, Rules, Tactics, Scope) of the video services market will be analyzed.