标签：#sass

If your app sells an allowance, a number of credits a month, or a number of documents, or a number of anything. Whatever it is, you end up writing a balance somewhere, a reset when the period rolls over, a check before the expensive call, and a usage screen that has to agree with all of it. None of that is hard on its own. What gets you is that the pieces drift. The plan says a thousand a month, the reset runs on the first of the month, the subscription renews on the 18th, and the screen sums a table that the charging code stopped writing to two features ago. And then somebody adds a weekly cap and now there are two numbers per plan to keep consistent, times seven plans. So after repeating the same on many apps, just created Larameter. It's basically what you see in Claude or OpenAI subscription plans. It meters credits against a plan, enforces ceilings on things that exist rather than things that are spent, and works out which plan an account is on instead of storing it. How to install Just install the package via composer as usually: composer require edulazaro/larameter php artisan vendor:publish --tag = larameter-config php artisan vendor:publish --tag = larameter-migrations php artisan migrate Then add the trait to whatever you bill. An organisation, a user, a workspace: the package does not care, and it does not need a column on your table. use EduLazaro\Larameter\Concerns\HasCredits ; class Organization extends Model { use HasCredits ; } The account row appears the first time you touch it. What are allowances One period is rarely enough. A monthly figure alone lets a bad afternoon eat the month, so you want a weekly cap on top, and maybe a per-session one. Declare those windows once: 'windows' => [ 'session' => [ 'minutes' => 300 , 'anchor' => 'rolling' , 'share' => 0.04 ], 'weekly' => [ 'days' => 7 , 'anchor' => 'fixed' , 'share' => 0.25 ], 'monthly' => [ 'months' => 1 , 'anchor' => 'fixed' , 'share' => 1 ], ], And then a plan grants 1 figure , which every wi

I'm a solo dev with zero users right now, and I just spent an afternoon on a decision most people would've hardcoded in five minutes. Here's the setup. NotebookBloom is my Chrome extension for Google's NotebookLM. At launch I don't want to charge for much — I want people to actually use it, tell a friend, leave a review. So the plan is: only cloud sync (Google Drive backup) is Pro on day one. Everything else — flashcard export to Anki, citation export, bulk import — free. But "free on day one" implies "not free forever." Once there are enough users, I want to flip some of those to paid, one at a time, watching what happens. And that's where I hit a wall that only exists for extensions: there is no server runtime. My extension runs in the user's browser. So if I write "is this feature paid?" as a hardcoded if in my code, then flipping it later means: edit code → rebuild → upload to the Chrome Web Store → wait for review[你查到的审核时长，如 "usually under a day, sometimes 3"]. Think about that. A pricing change — arguably the most business-critical lever I have — would be stuck in a review queue. That's absurd. So I stopped and rebuilt it as a switch. One file, features.ts , with a single decision function: canUse(feature, isPro, gates) → isPro OR the feature isn't currently gated Four flippable keys: cloudSync, ankiExport, citationExport, bulkImport. The default (compiled into the extension) is: cloudSync = paid, the rest = free. That's my day-one tiering. The switch values live in my Cloudflare Worker's KV. To flip Anki export to paid, I change one KV value — no rebuild, no store review. Every user picks it up within a day. The part I'm quietly proud of: it costs zero extra requests. The extension already calls /status to check "does this Google account have a subscription?" (you can't trust the client to self-report that — that's how you get pirated). I just piggybacked the switch values onto that same response. The paywall config rides along on a request I was already maki

I came into this as a graphic designer, not a software engineer. I didn't have a computer science background, and a lot of what BrandStack needed — authentication, databases, payments, deployment — was new territory for me when I started. What made it possible wasn't some shortcut. It was breaking the problem down into pieces I could actually learn: how user accounts work, how a database should be structured so one person's data never leaks into another's, how to move from test payments to real ones without breaking checkout for actual customers. I made real mistakes along the way. Early on, every user shared the same underlying brand data because I hadn't scoped the database correctly to each account — a serious bug that I only caught by testing with two separate accounts myself. Finding and fixing that taught me more about proper application architecture than any tutorial could have. I don't think being a designer first is a disadvantage for building product. If anything, it means the interface and the experience get real attention, not just the backend logic. But it does mean being honest about what you don't know yet, and being willing to slow down and actually understand a problem instead of copying a fix you don't understand. BrandStack is still a work in progress. But it's a real, working product — built by someone who had to learn most of this from scratch, in public, one bug at a time.

When we started Reach , the plan was simple. We had a bunch of small businesses we were already in touch with - real SMBs, the kind that live on WhatsApp and don't have a "tech team." We'd give each of them an AI agent that talks to their customers, hand them a clean starter template for the instructions, and let them tweak it from there. That was the whole bet: give people a good starting prompt and a template, and they'll play along. We were so wrong it's almost funny now. The part nobody warns you about Here's the thing about prompt engineering that you only learn by watching non-technical people try to do it: writing the instructions is not the hard part. The hard part is thinking about the task in the abstract . We'd hand a business owner an agent that mostly worked, and say "just adjust the instructions when it gets something wrong." Sounds easy. It is not. Sitting down and imagining all the ways a conversation could go, then writing rules for a machine to follow - that's a skill. It's basically a job. And it's a completely different job from running a flower shop or a real estate office. So they got stuck. They'd open the instructions editor, stare at it, and close it. The agent stayed mediocre because the iteration loop we designed required them to be part-time prompt engineers. A few of them just quietly left. That stung, but it taught us the actual problem. What "iteration" actually looked like We started doing the iterations for them, manually. And once we did that a few dozen times, a pattern jumped out. The feedback never led to an abstract change. It was never something that made us "rethink the agent's persona" or "restructure the system prompt." It was tiny, concrete, and tied to a real conversation: "It suggests all of our services, but honestly most customers only care about these three - push those." "It pulled our opening hours from the website and they're just wrong. We changed them months ago." These were one-line corrections. The owner knew ex

This is a submission for the June Solstice Game Jam ( https://dev.to/challenges/june-game-jam-2026-06-03 ) What I Built I built Solstice Assassin, a tactical stealth-action game set inside a collapsing digital mainframe. You play as Alex, a self-aware digital anomaly trapped inside the Solstice Grid, a secure virtual system originally created by Alan Turing. Alex awakens with almost no memory except one critical piece of information: «CREATOR: ALAN TURING» The catch? Today is the Summer Solstice, the longest day of the year, and at midnight the system will execute a complete purge of all dynamic data. Alex has one final day to recover lost memories, outsmart the system's security forces, and find a way to survive. Gameplay combines tactical movement, stealth, procedural level generation, enemy AI, and resource management. Players infiltrate security sectors, collect awareness data, avoid or eliminate hostile "Cleaners", and manage powerful abilities such as Dash, Cloak, Radar, and Time Warp. The Solstice theme isn't just part of the story—it directly affects gameplay. Throughout each mission, the system progresses through different Solar Phases: 🌅 Golden Dawn ☀️ High Noon 🌇 Crimson Sunset 🌑 Eclipse Each phase changes visibility, stealth effectiveness, enemy behavior, and the overall tactical landscape. High Noon makes players highly exposed, while Crimson Sunset rewards stealth and careful planning. By the time Eclipse arrives, the entire system begins breaking down. My goal was to create a game where the passing of the longest day isn't just a background theme but something the player constantly feels through the mechanics themselves. Video Demo https://youtu.be/48RM1iTZjOg?si=JYz86wVzNMjeZmmw In the video I demonstrate: Tactical movement and infiltration Dynamic Solar Phase transitions Enemy AI behavior and pathfinding Awareness recovery and progression systems Alex's abilities AI-generated mission briefings and voice interactions Procedural level generation End-o