Останнім часом я чимало писав про свої думки щодо незалежної розробки. Я хотів узагальнити їх, розповівши про шлях Mole від CLI з відкритим кодом до платного програмного забезпечення для Mac — про те, що я думав у той час, що насправді спрацювало, і, можливо, дати кілька порад друзям, які працюють над власними проєктами.
Офіційний веб-сайт Mole —
mole.fit , а CLI з відкритим кодом доступний на
GitHub . Ви можете спочатку спробувати.
Минулого року під час святкування Національного дня я написав кілька сотень рядків коду біля басейну в Санья і створив інструмент командного рядка для очищення Mac під назвою Mole CLI, який я опублікував у відкритому доступі на GitHub. Спочатку я планував його лише для себе та колег. Як виявилося, менш ніж за рік він отримав 60 000 зірок, вийшло понад 50 версій, 121 розробник з усього світу надіслав код, і було вирішено майже 800 пропозицій щодо функцій та помилок.
Насправді я не зовсім усвідомлював, скільки людей ним користуються, поки одного разу, через те, що у мене в README було два зображення, прискорені Vercel, трафік перевищив ліміт оплати, і я заборгував Vercel 80 доларів. Тоді я зрозумів, що настав час створити десктопну версію.
Раніше найпоширенішим типом електронних листів, які я отримував, були від міжнародних користувачів, і загальний зміст був таким: «Мої батьки користуються Mac, моя сестра теж, але вони не знають, як відкрити термінал. Чи не могли б ви зробити версію, яка не вимагає введення команд?» Я відкладав це на деякий час, головним чином тому, що вважав, що сам CLI ще недостатньо зрілий. Пізніше я витратив два вихідні на створення десктопної версії для Mac. Я опублікував її о 10 вечора тієї ночі, і сповіщення дзвеніли всю ніч — французькі, німецькі, всілякі валюти. Зрештою я вимкнув сповіщення електронною поштою, щоб хоч трохи поспати. Озираючись назад, той перший реліз був досить сирим; наскільки завершеним може бути щось, створене за два вихідні? Багато функцій було додано поступово протягом наступних місяців. По суті, це була група користувачів, які спочатку заплатили, а потім супроводжували мене, щоб завершити його. CLI залишається незмінним, все ще з відкритим кодом і безкоштовним, і продовжуватиме оновлюватися; платною є лише десктопна версія.
Три типи сміття, створеного ШІ
Після створення десктопної версії функцією, якою я сам користувався найчастіше, було очищення, тому що мій Mac справді був доведений до межі ШІ. Я тримаю Claude Code і Cursor відкритими цілий день, щоб писати речі. Спочатку я не звертав особливої уваги, але пізніше виявив, що сміття, залишене ШІ, дуже відрізняється від традиційного програмного забезпечення, і поділяється приблизно на три категорії.
Перша категорія — це артефакти компіляції. Це не новина, але ШІ збільшив масштаби. Раніше я міг вручну написати кілька сотень рядків коду і скомпілювати три-п'ять разів на день; тепер я дозволяю агенту запустити десяток раундів за один день, компілюючи щоразу. Rust project targets, frontend .next та dist папки, а також DerivedData від Xcode ростуть дуже швидко. Якось я очистив 86 ГБ лише цих речей. Друга категорія — це старі версії, залишені самими інструментами ШІ. Інструменти командного рядка, такі як Claude Code, Cursor Agent та GitHub Copilot, автоматично оновлюються. Вони оновлюються, завантажуючи повну нову версію в новий каталог — кожна версія близько 250 МБ — а старі не видаляються. За кілька місяців може накопичитися десяток непотрібних версій. Третя категорія — це файли моделей — моделі, завантажені Ollama та LM Studio, а також кеш HuggingFace, які часто займають десятки гігабайт.
Mole очищає перші дві категорії, але не чіпає жодного байта з третьої. Пізніше я поступово продумав це в трьох рівнях, категоризуючи все, що сканується, перш ніж вирішити, чи слід його позначати за замовчуванням. Перший рівень — це те, що можна відновити: HTTP-кеші, кеші GPU, артефакти компіляції та більшість логів. Якщо відповідний додаток вийшов і шлях вільний, його можна очистити. Другий рівень має високу вартість відновлення: кеші реєстру менеджерів пакетів, локальні ваги моделей та iOS DeviceSupport можна відновити, але це коштує пропускної здатності та часу, тому користувач повинен сам подивитися. Третій рівень — це те, що не можна замінити: історія чатів, бази даних електронної пошти, бібліотеки фотографій та стан поточних проєктів. Я вважаю, що ці речі ніколи не повинні потрапляти до списку одноразового очищення.
Стиснення цих трьох рівнів в один список «безпечних для видалення» було б простіше, але ціною є прийняття рішення за користувача. Десять категорій на сторінці очищення розташовані в такому порядку: відновлювані кеші зверху, і чим далі вниз, тим більше потрібно перевіряти самостійно.
Такі речі, як target, build, dist, __pycache__ та DerivedData, можна повернути повторною компіляцією, ціною кількох хвилин роботи процесора. node_modules, Pods, venv та vendor також виглядають як каталоги залежностей, але їх видалення вимагає повторного завантаження з Інтернету. Якщо ви в швидкісному поїзді або літаку і хочете запустити проєкт, ви просто застрягнете в очікуванні. Ці дві категорії виглядають схоже і легко очищаються разом як сміття. Mole CLI робив це раніше, але пізніше я спеціально видалив усі каталоги типу завантажень зі списку очищення версії для Mac.
Моделі є найважчою категорією тут. Повторне завантаження десятків гігабайт — це катастрофа, і звичайний інструмент очищення навіть не видалить їх правильно. Ollama розбиває моделі на купу блоків, названих за хешем; кілька моделей можуть спільно використовувати один і той самий блок. ollama rm обчислює, чи хтось інший все ще посилається на блок, перш ніж наважитися його звільнити. Якщо ви вручну видалите великий блок з файлової системи, ви можете зламати іншу модель. Тільки сам інструмент розуміє ці посилання.
Тому такі шляхи, як ~/.ollama/models та ~/.cache/huggingface, жорстко закодовані в список захисту в коді. Вони навіть не з'являться під час фази сканування; вони показують лише зайнятий розмір у розділі аналізу диска, залишаючи управління самими моделями Ollama або LM Studio.
Є ще одна категорія речей, навіть більш недоторканних, ніж моделі: записи сеансів ШІ. ~/.codex/sessions, ~/.claude/projects та ~/.grok/sessions зберігають ваші повні діалоги зі ШІ за місяці або навіть рік. Вони містять ваші думки на той час, відхилені рішення та причини кожної зміни. Якщо їх видалити, вони справді зникнуть, і в певному сенсі вони цінніші за сам код. Тому ці шляхи ніколи не будуть очищені в Mole, незалежно від того, як довго вони там лежать. Також захищені спогади, плани, навички та згенеровані зображення.
Ці списки захисту не були продумані з самого початку; вони були переважно вивчені методом проб і помилок. Найдурнішою помилкою був com.apple.e5rt.e5bundlecache. У назві є «Caches», і він знаходиться в каталозі кешу, тому виглядає як кеш, але насправді це модель, скомпільована нейронним двигуном Apple. CLI на ранніх етапах сприймав його як кеш і очищав, що призводило до збою всіх додатків, які використовують функції розпізнавання, до перезавантаження. З тих пір у мене з'явилася звичка: коли я бачу каталог зі словом «cache» в назві, я ставлю собі три запитання: Хто це написав? Хто прочитає це після перезавантаження? Як я це поверну, якщо випадково видалю? Якщо я не можу відповісти на одне з них, я не чіпаю це.
Подивись, перш ніж видаляти
Я оцінюю якість цього типу інструментів не за тим, скільки він може очистити, а за тим, чи дозволяє він чітко бачити перед видаленням.
Коли Mole очищає, він спочатку сканує, перераховує елементи один за одним і показує, що саме являє собою кожен елемент, де він знаходиться і скільки місця займає. Елементи, в яких я не впевнений, за замовчуванням не позначені. Ви підтверджуєте перед видаленням, а під час видалення елементи спочатку потрапляють у Кошик, щоб їх можна було відновити, якщо ви передумаєте. Сканування та очищення виконуються повністю локально; файли та результати ніколи не завантажуються. Ціна цього — повільніша робота та додатковий крок підтвердження, що може здатися нудним, коли ви поспішаєте, але я краще пропущу видалення, ніж видалю щось помилково.
Видалення слідує тій же логіці. Коли ви вибираєте додаток, Mole знаходить все, що розкидано по системі, позначаючи кожен елемент його шляхом і розміром. На зображенні вище сам додаток Claude займає лише 781 МБ, але ~/Library/Application Support/claude — 7,67 ГБ. Ніколи не сам пакет додатку займає справжнє місце. Елементи входу та фонові служби також знаходяться на тій же сторінці, тому вам не доведеться шукати їх у Системних налаштуваннях.
Наприклад, інсталятори оновлень системи macOS — каталог /macOS Install Data — часто перевищують 10 ГБ і виглядають як ідеальні цілі для очищення. Але системі вони все ще можуть знадобитися для завершення оновлення; видалення їх занадто рано може запобігти завантаженню машини. Тому в Mole це непозначений елемент для перевірки з трьома рівнями захисту: якщо оновлення очікує на встановлення, весь рядок прихований; якщо до інсталятора зверталися за останні 14 днів, він прихований; якщо процеси, пов'язані зі встановленням, все ще працюють, він прихований. Якщо будь-який сигнал не може бути прочитаний, це вважається ризиком і взагалі не відображається.
У момент виконання скрипт із привілеями root знову виконує ці перевірки. Якщо вони не пройдені, він завершується з ненульовим кодом. Ви не побачите ситуації, коли «звіт показує, що очищено 12 ГБ, але жоден байт не було переміщено».
У мене є дуже простий спосіб визначити, чи хороший інструмент для очищення. Встановіть два продукти від одного виробника, видаліть лише один і подивіться, чи включає він спільний батьківський каталог Application Support або груповий контейнер. Якщо так, це означає, що він збігається за назвою, а не за власником. Я не наважуся дозволити інструменту, який не може навіть з'ясувати право власності, масово видаляти речі.
Він не буде вас турбувати зазвичай
Очищення 86 ГБ за один раз досягається не видаленням кількох логів; під час видалення Claude ви можете знайти речі, в десять разів більші за сам додаток, розкидані по всій системі. Він знайде те, що потрібно знайти, але не буде активно вас турбувати.
Після встановлення він не буде вискакувати зі сповіщеннями кожні кілька днів, нагадуючи вам очистити, і не вистрибуватиме після сканування, щоб сказати, наскільки небезпечний ваш комп'ютер. Відкривайте його, коли хочете очистити; коли ні — його ніби не існує.
Інтерфейс слідує тій же філософії. Якщо сканування не завершено, він не переходить на сторінку результатів. Для речей, які будуть готові за мить, він навіть не показує індикатор завантаження; лише через деякий час з'являється анімація «зайнятий». Сторінка завершення також має заздалегідь зарезервоване місце, щоб вікно не стрибало, коли з'являються результати. Всі ці правила дуже тривіальні, але разом вони є причиною, чому він відчувається стабільним у використанні.
Основні завдання за своєю суттю непередбачувані, тому додавання анімації не допомагає; сам процес повинен бути надійним. Я не хочу мати інструмент обслуговування, який потребує постійного моніторингу. Ініціюйте завдання, зачекайте, поки воно завершиться, а потім заберіть екран — цього достатньо. Йому не потрібно постійно блимати, нагадуючи вам подивитися на нього.
Доступність також є частиною цього. Порядок читання, операції з клавіатурою та стабільність фокусу — все це частина того самого «тихого» досвіду. Коли в системі ввімкнено «Зменшення руху», планети припиняють своє декоративне обертання, а зміни стану зменшують просторові рухи. Жодна операція не залежить від того, чи розуміє користувач анімацію.
Зробити його зручним навіть для 70-річного
Раніше, коли я щось робив, я в основному враховував лише те, чи буде це зручно для моїх колег і друзів. Переходячи від CLI до десктопної версії, я зрозумів, що зробити його зручним для 70-річного дідуся вимагає набагато більше, і це набагато цікавіше. Нижче наведено все, що взято з електронних листів користувачів за останні три місяці; мої найбільші здобутки майже всі тут.
Британський користувач майже 70 років сказав, що у нього стався «старческий провал» і він знову купив Mole. «Вважайте другий платіж подарунком для вас; дякую за цей чудовий інструмент, він заощадив мені набагато більше фунтів, ніж CleanMyMac.» Я запропонував йому повернути гроші або подарувати зайву ліцензію. Він перевірив і відповів наступного дня: «Жоден із моїх сусідів не користується Mac, так само як і мої підписники на Bluesky. Цей рахунок за мій рахунок.» Отримувати такі листи змушує мене відчувати, що я повинен зробити продукт ще кращим, щоб бути гідним цієї довіри.
Американський користувач виправив мою помилкову думку щодо регіональних звичок. Я завжди думав, що американці повинні використовувати Фаренгейт для температури, тому я встановив Фаренгейт за замовчуванням для регіону США. Він сказав: «Американці використовують Цельсій у всіх технічних контекстах; лише погода та температура тіла є винятками. Я був вражений, побачивши 110, коли встановив Mole. Технічні характеристики, які Apple показує американцям, також у Цельсіях, і fastfetch/neofetch за замовчуванням використовують Цельсій у системах США. Я пропоную залишити перемикач Фаренгейта, але встановити Цельсій за замовчуванням для всіх регіонів.» Пізніше я змінив це на Цельсій за замовчуванням з перемикачем на Фаренгейт. Він також надіслав наступний лист про ціноутворення, сказавши, що число, яке я вказав, не схоже на навмисно встановлену ціну, а скоріше на конвертацію з іншої валюти. Він додав: «Під "іноземним" я маю на увазі не антикитайське, а те, що люди хочуть відчувати, що автор їх розуміє.» Чесно кажучи, я просто вигадав цю ціну; я ніколи серйозно не думав про ціноутворення, перш ніж зробити продукт. Бути викритим незнайомцем було досить ніяково — виявляється, ціна також впливає на рішення користувача.
Користувач із легким порушенням зору сказав: «Виглядає як дуже гарний додаток, але, на жаль, я не можу ним користуватися; здається, у нього жорстко закодований темний режим. Моя система налаштована на світлий режим, і я використовую лише додатки зі світлим режимом.» Зробити Mole лише темним було свідомим рішенням; панель меню плаває над шпалерами, як HUD, і темне скло має менше відблисків, що усуває необхідність перемикання теми. Але ця причина не спрацювала для нього. Я завжди вважав, що серйозно ставлюся до доступності, але повністю не зміг усвідомити, що світлий режим сам по собі є вимогою доступності. Минуло вже чимало часу з моменту отримання того листа, а Mole все ще лише темний; світлий режим все ще в списку, не завершений. Я відчуваю себе трохи винним, що продукт, який претендує на турботу про доступність, змусив користувача, який прямо сказав, що не може ним користуватися, чекати так довго.
Викладач з німецького університету подав заявку на освітню ліцензію, сказавши, що це «не лише підтримка для мене особисто, але й значуща підтримка на освітньому рівні». Виявляється, міжнародні викладачі використовують мій продукт у класному середовищі — випадок, якого я не передбачав. Угорський лікар дав найчесніший негативний відгук: «Чесно кажучи, ціна трохи висока для того, що може зробити безкоштовний додаток.» Я не вважав це образливим; купівельна спроможність сильно відрізняється в різних країнах. Він не скаржився; він допомагав мені визначити проблему.
Мої улюблені функції в Mole насправді не були моїми ідеями. Сповіщення про низький заряд батареї AirPods було додано, коли я працював над здоров'ям батареї; я не стикався з цим сценарієм, поки одного дня не отримав його — це було дуже продумано і ненав'язливо. Я додав три різні варіанти поведінки для утримання екрана увімкненим після нагадування користувача; коли я раптово виходжу на вихідні, ШІ-кодування може продовжувати працювати, що економить мені багато асинхронного часу. Можливість бачити рівень заряду батареї iPhone у статусі було важко реалізувати спочатку, але я зрештою знайшов спосіб. Все це були речі, які користувачі просили мене додати, і врешті-решт я отримав від них найбільше користі.
Я насправді відповідав на листи вручну
Запитання та відповіді, повернення коштів та скидання кодів активації становлять менше 1% від бази користувачів. Я міг би написати скрипт за півгодини, щоб автоматизувати все це, але я цього не зробив. Тільки обробляючи їх один за одним, я можу відчути, чого насправді хочуть користувачі, чому вони повертають гроші і що їх турбує — і це часто не те, про що вони запитують в першу чергу. Мій поріг для автоматизації — коли три речі є правдою: проблема повторюється, відповідь стабільна, а всі винятки зрозумілі. До тих пір я краще відповідатиму по одному. Це все ще ефективно; я не витрачав гроші на маркетинг, і зростання в основному відбувається завдяки сарафанному радіо. Рівень повернень нижче 0,8%. Багато покупців є давніми користувачами CLI.
Перед релізом я не налаштовував систему тікетів, платформу підтримки клієнтів або базу знань. Інженери люблять спочатку створювати ці системи підтримки, тому що це знайома робота, і ШІ стиснув її до півдня, що робить її легшою для занадто раннього початку. Але хоча на створення йде лише півдня, обслуговування є довгостроковим зобов'язанням, і воно поки що просто не потрібне. Того дня, коли вхідні повідомлення почнуть втрачати запити, час відповіді стане незрозумілим або на одне й те саме запитання будуть різні відповіді — тоді дійсно знадобиться нова система. ШІ робить багато частин цього продукту можливими, але спілкування з людьми не можна замінити ШІ; інакше це не було б цікаво. Він може підвищити ефективність, але важко покращити взаємні почуття та довіру. Це також може бути способом для продуктів, народжених з ШІ-кодування, зберігати людський дотик.
Речі, які я вважав корисними
У створенні продукту я відчуваю, що здатність кодувати становить лише близько 30%. Більше зусиль йде на з'єднання ваших власних больових точок з больовими точками більшості користувачів, створення чогось, що легко використовувати без інструкції, і просування цього перед правильними людьми, щоб вони відчули, що це вирішило велику проблему. Інженер продукту — це приблизно комбінація дослідника, продакт-менеджера, інженера, операційника, аналітика даних та бізнес-стратега.
Те, що ви не робите, набагато важливіше за те, що ви робите. Для інструменту, який видаляє ваші файли, це стає тим, що ви не видаляєте. Ті жорстко закодовані списки захисту всі походять з цього правила. Мені пощастило прочитати багато книг про інженерну культуру, коли я починав як першокурсник; фрази на кшталт «сутності не слід множити без необхідності» та «простота — це найвища витонченість» повільно проникли в моє життя, роботу та код. Я відчуваю це ще глибше після створення продуктів. Різниця між хорошим продуктом і середнім значною мірою полягає у здатності вирішити, чого не робити. Деякі функції самі по собі хороші, але якщо вони не на головному шляху, я їх не включаю; інакше це легко перетворюється на купу функцій, які важко підтримувати.
Ще одне відчуття полягає в тому, що ви повинні мати дорожню карту на наступні шість місяців у голові, чітко знаючи, що додати в кожній версії, які є фальшивими потребами, і які функції слід розмістити там, де вони зручні для користувачів. Для звичайних користувачів той, яким ви можете користуватися без читання інструкції, є хорошим. Позиціонування Mole — це тихий охоронець обслуговування системи Mac. Багато друзів пропонували чудові функції, від яких я ввічливо відмовився. Моя мета проста: якщо один із кожних ста користувачів Mac готовий залишити Mole, це вже достатньо корисно.
Тепер, перш ніж функція потрапить у дорожню карту, вона повинна пройти три ворота: не може бути постійних таймерів, слухачів або накладних витрат на вибірку, якщо користувач не натиснув на функцію; ви не можете розширювати привілейованих помічників або додавати нові системні дозволи для невеликої зручності; і ви не можете додавати налаштування, коли є розумні значення за замовчуванням. Це не універсальні принципи для всього програмного забезпечення, а правила, які Mole встановив для себе. Кожне додаткове постійне завдання, привілей та конфігурація вимагають від користувача трохи більше довіри до вас.
Я в основному не накопичую для «великих кроків»; я намагаюся випускати версію щотижня, щоб проблеми користувачів вирішувалися швидко і я міг вести діалог. Кожен реліз, оновлення та просування є чудовою можливістю для спілкування і дозволяє людям, які не бачили новин, знати, що ви робите.
В епоху ШІ бар'єри коду стають меншими. Те, що потребує більшого контролю, — це те, як витрачати Tokens саме на вирішення проблем користувачів. Я не проти витрачати більше, але це повинно бути ефективно — наприклад, ретельно обговорювати вимоги, копатися в даних, щоб знайти справжню проблему, і писати текст, який люди розуміють з першого погляду. Ці сфери варті витрат. Я розглядаю Tokens як інвестицію, а інвестиції повинні приносити прибуток.
Mole був глобальним з першого дня, і я публікую більше англійського контенту, ніж китайського. Моє відчуття за цей час полягає в тому, що світ величезний, база користувачів широка, і вони готові довіряти вам з самого початку. Люди, яким ви допомагаєте принагідно, часто стають вашими користувачами пізніше, тому що була реальна взаємодія. Я не витрачав гроші на просування; сплески на X високі, але короткочасні, тоді як речі, опубліковані на YouTube, згасають дуже повільно. Поки контент хороший і хтось його рекомендує, він може жити там довгий час.
Я витратив більше часу на дані, ніж уявляв. Перегляд продажів за вимірами та часом, у поєднанні з даними про трафік, коментарями користувачів, усіма записами взаємодій з користувачами, причинами повернень та всіма проблемами з боку відкритого коду — все це дорогоцінні ресурси. Вони допомагають мені виявити багато проблем, про які я не знав, і побачити, де саме розривається воронка продажів.
Останній пункт більше стосується мого власного підходу. Створення акаунта з глибоким утилітаризмом викликає тривогу; я вважаю за краще будувати його як бренд, де я сам є брендом. Мої думки, ідеї, оновлення продукту, інсайти, взаємодії та коментарі — все це додає довіри до цього бренду. Довіра особливо важлива в сьогоднішньому фальшивому, але процвітаючому світі ШІ. Речі, які звучать дивовижно, але відчуваються посередніми, коли ви натискаєте, вже знизили очікування багатьох користувачів. Навіть якщо у вас дійсно хороший продукт, ви не отримаєте уваги без довіри. Це можна робити дуже довго; поки ви в Інтернеті, цей бренд житиме — це продукт із найдовшим життєвим циклом у вашому житті.
Чому п'ять планет
Mole desktop наразі має п'ять модулів: Очищення, Видалення, Оптимізація, Аналіз диска та Стан обладнання. Кожен модуль відповідає планеті в інтерфейсі: Очищення — Земля, Видалення — Марс, Оптимізація — Меркурій, Аналіз — Юпітер, а Стан — Сонце. Це пов'язано з моєю дитячою любов'ю до спостереження за орбітами планет, плюс те, що перше, чого я дійсно хотів навчитися після вивчення фронтенду десять років тому, був WebGL. Текстури планет змінювалися не менше 10 разів; я завантажив багато з офіційного веб-сайту NASA, перш ніж зупинитися на них. Напрямок обертання, швидкість та ефекти польоту після завершення відповідають реальним небесним тілам.
Цю частину можна було б опустити; невеликий інструмент у рядку меню, який очищає одним кліком, теж би спрацював. Але кібер-сміття, створене ШІ, вже достатньо. Замість того, щоб використовувати Tokens для створення ще одного інтерфейсу, який ледве працює, я хотів зробити щось трохи більш комфортне — не витрачати мої Tokens і не засмічувати вашу стрічку.
Мені подобається, коли речі відбуваються природно, а не домагатися результатів за короткий час; ці три місяці це підтвердили. Нещодавно я придумав фразу: Найкраща робота у світі, мабуть, для того, хто постійно навчається на вільному ринку, використовувати своє судження, здатності та естетику, щоб постійно створювати цінність, за яку інші готові платити.
CLI має відкритий код і є безкоштовним на GitHub, а десктопна версія для Mac знаходиться на офіційному веб-сайті mole.fit.
Оскільки це мій перший досвід створення платного продукту, можливо, я не продумав деякі моменти. Я буду вдячний за поради та рекомендації від досвідчених друзів. Згадані вище зміни не були моїми ідеями; усі вони з'явилися завдяки електронному листу або issue від користувача. Тож ніколи не втрачайте можливості спілкуватися з користувачами; слухайте їхні скарги та пропозиції скільки завгодно — вони можуть вам дуже допомогти та дозволити краще зрозуміти своїх користувачів.
