The development of the platform "INTUARY AI" was instrumental in developing my skillset.
The name Intuary may not be immediately recognisable as an English word, but the word "intueri" means 'to gaze upon' in Latin and is the root word for intuitive in English. The choice to select this name was driven by the root driver for this system - to create consumer software that was inherently intuitive to use.
Whilst the current status of Intuary as consumer software is currently prelaunch, that does not mean that the product itself is a simple throw-away. The system is a collaborative, block-based canvas workspace, with a built-in AI chat system with RAG for context delivery, all fed by an AI analysis pipeline that can handle uploaded audio, live recorded audio via microphone and text uploads (e.g. heavy PDF files etc.). On top of this - a capture daemon is built and available to download, which picks up a user's system audio directly and then feeds the audio back into the AI pipeline - allowing users to stay native in their browser. The system capture is completely optional and is the only downloadable piece of software required in the entire system.
The part that I'm most proud of is not anything labelled above; it is the simple underlying philosophy of what was built. Early on, the system was built entirely in JavaScript; I migrated the system to TypeScript with a Next.js frontend and an Express backend, Firebase Functions for heavy compute work (AI analysis) and Vite for the Landing/Marketing site. There was not a single "any" type in the codebase across all 4 fronts, and the linting rules were extremely strict. The goal behind this was not only to produce a high-quality software product, but I personally was hyper-aware that the time spent engineering the system was intentionally never going to be time wasted regardless of whether commercial success came, because of 2 underlying factors:
- The asset is a defensible portfolio piece for any future competency checks.
- I threw myself in the deep end as far as challenging engineering problems as well as holding the quality bar at the highest standard and not accepting anything below it, which forced me to rise to that level.
The second one being the more important one in my eyes - challenging yourself with tackling hard problems (low-level system audio capture, real-time multi-client collaboration etc.) whilst also ensuring that the solutions were not hacks/path of least resistance - sets up a defensible skillset/approach to engineering as a whole that will survive past the current project.
Now another important note is this - A public release is not scheduled currently, but this does not mean it is never to be scheduled. If the application needed to be released immediately today to gain users/traction and wouldn't work if released in 6 months, then I have simply built the incorrect product.
The goal was and still is to build an intuitive AI-native workspace platform, and that goal is still in progress.