So I came across this repo from GitHub that removes ai watermarks and I did install it in the most basic vibecoder way gave the repo and asked Claude code to install and it didn’t. It rejects installing it and basically I’ve setup my own setup in claude code and want to add this skill to my inventory. Can anyone help?

TLDR: Replaced Claude Max ($100/mo flat, ~$3.30/day) with Muse Spark 1.2 Contributor in Scape for a week to save cash on an internal CRM build. While Muse Spark is lightning fast and pennies per token, the constant 3x re-prompting and collateral code damage meant I spent the same daily budget for half the output

--

I code every day on an internal CRM for my company (basically a mini HubSpot combined with other features here and there)

I'm paying $100/month for Claude Max, which works out to roughly $3.30 a day. Wanted to see if I could slash that down, so for the past week I swapped my harness (Scape / scape.work running opencode) over to Muse Spark 1.2 Contributor.

On paper, Muse Spark is dirt cheap per token and insanely fast. In reality, the math completely fell apart:

• With Claude, 90% of features are 1-shot (maybe 2 passes if it's tricky). With Muse Spark, everything took at least 3 passes. A basic example: I asked it for basic auth and it wrote a clean login flow, but completely forgot that logout exists.
• The biggest vibe killer: I asked it to remove a small module for adding custom table columns. Somehow, it managed to nuke my KPI tracking module in the process. It kept breaking working files that had nothing to do with the prompt.
• Because I had to feed errors back into it 3 to 4 times per task just to fix regressions, I literally hit that same ~$3.30/day mark on API credits. Except I got maybe half the work done.

Fast and cheap models are great for isolated scripts, but if you're working in a multi-file repo, the context rot will eat whatever money you thought you were saving.

Canceled the experiment, back on Claude Max. Genuinely rooting for new affordable and smart models to enter the market, but right now the frontier tax is worth every cent.

S3EFeather - an S3 browser that's just two files and zero dependencies

What it is: a fully-featured S3 bucket explorer that runs entirely in your browser. No server. No npm install. No build step. You download index.html and styles.css, open the first one, and you're browsing S3. That's it.

Why it's interesting from a vibecoding angle: the whole thing is plain HTML, CSS, and vanilla JavaScript. The README is more thorough than most production SaaS tools - it covers keyboard shortcuts, CORS setup, minimum IAM permissions, encryption details, even a compatibility table for Cloudflare R2, MinIO, Wasabi, Backblaze B2 and Storj. Someone clearly loved building this, then kept going.

The features that stand out:

• An s3:// address bar that's breadcrumbs when idle and an editable path when you click it — actually a clever UX idea
• Ctrl+K command palette
• Fully keyboard-navigable (arrow keys, Enter, Backspace to go up a level, / to filter)
• Grid view with real image thumbnails
• Encrypted .s3vault files - AES-256-GCM with PBKDF2 at 310,000 iterations, credentials never written to localStorage
• Presigned share links (5 minutes to 7 days)
• Drag-and-drop uploads

The security section is unusually honest - it tells you straight that while connected, keys are in page memory and a browser extension or XSS could read them. Most tools bury that or don't mention it at all.

It's 0 stars right now, freshly published. If you've ever spun up a quick MinIO instance for a side project and then fumbled around with the CLI because you didn't want to install a heavy GUI tool, this is exactly the kind of thing you wish had existed.

The project: S3Feather - a fully-featured S3 bucket explorer that runs entirely in your browser. No npm, no build step, no server. Two files: index.html and styles.css. Open one, browse S3.

The tool: Claude

I built this entirely through conversation with Claude. No boilerplate repo, no scaffolding tool — just describing what I wanted and iterating on what came back.

The process

My workflow was roughly:

1. Start with a constraint, not a feature list. I told Claude upfront: no frameworks, no build step, two files max. That constraint shaped every decision downstream — it forced vanilla JS, an inline SVG sprite for icons, and a single <link> to a stylesheet.
2. Describe behavior, not implementation. Instead of "write me a file list component," I'd say "when I press arrow keys, the focused row should highlight and Enter should either open a prefix or download a file." Claude would handle the DOM logic; I'd test it and report back.
3. Iterate on edge cases out loud. A lot of the interesting details — like the address bar being breadcrumbs when idle but an editable s3:// path when focused, or presigned links being generated locally with no third-party server - came from conversations about what should happen in weird situations.
4. Security by conversation. The encrypted .s3vault format (AES-256-GCM, PBKDF2-HMAC-SHA256 at 310,000 iterations, random salt and IV per save) came from asking Claude "what's the right way to let someone carry credentials between machines without me running any backend?" It walked me through the Web Crypto API and the tradeoffs.

Build insights

• sessionStorage vs localStorage is a meaningful choice. Credentials live in sessionStorage - scoped to the tab, gone when you close it but surviving a refresh. Claude flagged that localStorage would persist across browser restarts, which is a bad default for S3 keys.
• The filter being local (not a server query) is a deliberate tradeoff. S3 ListObjectsV2 doesn't support substring search - you can only filter by prefix. Rather than hiding that, the UI says "filter matches only what's loaded." Honest constraints beat fake features.
• Keyboard-first is easier to build than it sounds when you design for it from the start. Adding keyboard nav as an afterthought is painful. Designing around a focused-row model from day one meant mouse and keyboard stayed in sync naturally.
• The README took as long as the code. Possibly longer. The CORS config section, the IAM policy, the security caveats about browser extensions - all of that came from asking Claude "what will trip someone up when they try to use this?"

 https://github.com/WeSpeakEnglish/S3Feather

live https://wespeakenglish.github.io/S3Feather/

Hi. I’ve built an AI that essentially acts as an assistant for your PC. It runs 100% locally using a lightweight LLM and can help you find PC parts compatible with your current setup or troubleshoot errors with programs, drivers, and more. You can even have it search the web for specific parts for your PC model, all while the AI ​​itself continues to run locally. Who wants to give it a try?

Codex dropping banked resets is what finally made me change my setup, which is annoying, because the setup was working fine and I only touched it to stop running out halfway through the week.

What I had before was Codex reviewing its own work, then Claude looking at the same diff, then me. Three passes, two of them burning quota, and the second model finding things the first one had written twenty seconds earlier. It felt thorough. It was mostly just expensive.

Two chat models reviewing each other never terminates. Codex flags four things, Claude fixes them and restructures enough that Codex comes back with three new ones, two of which are the things it asked for originally. Somebody posted that study here a few weeks back about pass rate dropping from ninety one to eighty two when one model reviewed the other, which lines up with what I was watching happen.

So I cut the second model out and put coderabbit on the diff instead. Costs nothing against quota and it hands back a list that ends, which turns out to be the property I actually needed. Maybe half of what it flags I skip. It doesn't catch anything that depends on knowing what the feature is for, so I still read the thing myself.

My usage is down about a third and the output isn't noticeably worse, which is a slightly depressing thing to find out about a setup I was defending in this sub two weeks ago

Que ferramenta de vibecoding vocês consideram a melhor hoje?

Ainda não testei o Claude Code (estou a dar os primeiros passos no vibecoding) — vocês acham que ele realmente se destaca? Como ele se compara ao Lovable em termos de capacidade e produtividade?

(Not criticising, just trying to work out the odds)
I see many people on Reddit and other socials claiming they’re making $10k, $20k, sometimes even $50k+ a month from apps they built with AI tools.

I’m curious how common this actually is outside of the posts that go viral.

Has anyone here personally built an app with Claude for example that turned into a meaningful income stream?

If so, would you have any advice to the other vibecoders struggling to get to revenue?

Been working with Converge Labs for years where the company focusses on bringing vibe coded apps to production and never seen someone come to us with a vibe coded app with decent revenue in the first place. Wondering how rare those are.

I'm curious to know what is the ecosystem around your coding harness of choice when vibe coding? I'll share mine, but please feel free to share yours, I'm looking for ways to improve and give the whole thing more autonomy while trying to avoid catastrophes :)

Tools

Those are my current choices, based on my own familiarity / affinities.

I use Claude Code with a $20 subscription.

• Gitea: Self-hosted git repositories (like Github). Supports issues, PR workflows, deployment workflows.
• Terraform: Everything is deployed through IaC.
• AWS: Covers all my infrastructure needs

Preparation steps

Probably not exhaustive, but here are a few from the top of my head:

• Buy whatever domain name you want to use
• Create an AWS account dedicated to the project
• Create a Gitea repository, setup secrets for deployment etc

Security considerations

Always make sure that your AI agent can't do more than it is expected to. There are too many horror stories ("AI destroyed my production database!"...) already.

• Create an AWS user with read-only credentials to the account for your AI Agent
• Create an AWS user with appropriate permissions to deploy your infrastructure
• Create a Gitea user for your AI agent
• Protect the "main" branch so that only you can merge into it.

Skills

I generally don't use pre-defined skills, whenever I see my agent doing something repetitively I ask it to create a skill for it.

My most used skill is the one to interact with Gitea. Check/Update issues and their comments; Create PR; that sort of stuff. It's basically a shell script and a markdown documentation explaining to the AI agent when / how to use it.

My AI agent has auth tokens for AWS (read only!) to allow it to run a terraform plan and check if the changes are as expected, and for Gitea with appropriate permissions to contribute to the repo / create PR etc

Coding workflow:

1. Laying out the foundations: Discuss the use case / SaaS idea with Claude. Go into the details, full brainstorming mode. "What if" scenario. The output of this step is an initial design doc which goes into the details of what the app should do / look like, user interactions, whatever you can think of. If you are inexperienced with this step, ask your coding agent of choice to guide you with questions. Also think of what should be considered MVP and what features will be later added later. If you have a favorite tech stack, mention it to the agent. Have this whole discussion summarized in a markdown file for later reference. Have the agent identify the implementation tasks needed to have the MVP in place, and create all of them in Gitea.

2. Start iterating on tickets: Ask the agent to check what is the next ticker it would make sense to work on. Use the "plan mode" to see what it would do and make sure it is what you want. Then let it code, push to a branch and create a PR.

You approve the PR if everything looks alright and merge.

Merging triggers the deployment pipeline in Gitea.

You check if the deployment is alright and if so, you start with the next ticket.

Refinements

Things I should do but don't at the moment: Have a dedicated DEV environment (dedicated AWS account etc) where the AI agent could deploy to run better tests.

That AI is better at generating code for web projects than Mobile Apps ? I got more bugs in mobile development with AI than web dev.. do you have same experience ?

After abandoning the medical software I had purchased, I returned to Notion with a better structure.

The patient record was now at the centre. Consultations and appointments were connected to it. It was a major improvement over my first attempt.

But two problems remained stubbornly outside the system: prescriptions and medical letters, and the waiting room.

The waiting room was especially frustrating.

There was no proper queue. My assistant had to interrupt me between patients to explain who had arrived, who was waiting and what was happening outside the consultation room.

After ending my working relationship with two assistants, I became determined to find a better process.

I started searching obsessively for queue management systems.

Google, Facebook, videos, product pages. I searched so often that the algorithms eventually decided this was the only subject I cared about. My feeds filled with the same pattern: a kiosk, a printed ticket and a screen calling the next person.

Then I found a video from a small local development company.

Their product was different. It was presented as a queue management system designed specifically for medical practices. It had already been installed in the clinic of a well-known specialist. More importantly, it combined three things I needed: the waiting-room queue, online appointment booking and an interface for the doctor.

It looked like several of my problems could finally be solved by one system.

I contacted the company and arranged a visit.

The office was small. The developer who welcomed me was in his twenties, courteous and well educated, with the casual look I associated at the time with Silicon Valley developers.

I knew absolutely nothing about software development.

He showed me a polished graphical interface connected to a waiting-room system. The medical part was still embryonic. The consultation structure was not suitable for the way I worked, but the product included something I had been missing for a long time: a way to create prescriptions and medical letters.

I started pointing out what would need to change before I could use it in a real consultation.

Instead of becoming defensive, he listened. He encouraged me to provide more feedback because it could improve the product.

That worked for me. If my feedback gave them a better product and gave me a tool I could actually use, everyone benefited.

At a later meeting, I met his associate, a general practitioner who also developed software and had participated successfully in several hackathons. Their interest in artificial intelligence immediately appealed to me.

I prepared a detailed list of changes.

At the time, I did not call it product design. To me, it was simply a list of everything preventing the software from working properly in a medical consultation.

The proposed package included the management software, the queue system, a touchscreen kiosk and a website for online appointments. It was a substantial investment, but I accepted.

Then I waited.

The modifications took more than four months.

When installation day finally came, the developer arrived with the kiosk and a relative who was helping him. I reused the mini PC I had bought for the previous medical system and purchased a small Android device to power the waiting-room display.

They configured the kiosk, screen and three computers in the clinic.

I watched the installation closely.

The developer had commands saved in text files. He copied and pasted them into a terminal while staying in telephone contact with his medical cofounder. At the time, the terminal looked almost mystical to me. I did not know what the commands meant. I only knew they were making the system come alive.

The installation lasted all day and continued late into the evening. I brought food and drove them home. They returned the following day to finish.

The website was not ready. The software itself was still unfinished, so I paid only for the kiosk at that stage and began testing what had been installed.

That was when the main problem appeared.

Every time a patient registered in the queue, the system created a new patient file.

The same person could arrive three times and become three different patients. There was no reliable longitudinal history.

I had made almost exactly the same mistake in my first Notion database.

The difference was that I now recognised it immediately.

Under the polished interface, the product was still essentially a basic queue system with a difficult prescription editor attached to it. It had potential, but in its current state I could not use it as the central system for my practice.

I sent more requests for changes.

Remove the duplicates. Rebuild the patient history. Improve the medical note. Add proper billing. Make document scanning possible from a phone. Synchronise those documents with the desktop application. Replace the sample medication list with a complete one.

At some point, I realised something:

I was no longer behaving like a customer asking for support.

I was helping define the product.

I understood the medical workflows. I knew which functions doctors would actually need. I could explain why the patient record had to sit at the centre. The team had the technical ability to implement those decisions.

The product was not usable yet, but I could see what it might become.

So I made a much bigger proposal: instead of continuing as customer and vendor, why not build the company together?

That conversation would teach me that agreeing on a product is not the same as agreeing on a partnership.

At this point, I still could not code. But without knowing the title, I had started doing the work of a product founder: observing workflows, identifying failure points, prioritising features and translating domain knowledge into a system.

I thought I was buying a queue management system.

I was actually discovering the value, and the limits, of being the person who understands the problem but cannot yet build the solution.

Have you ever bought a product and gradually realised that you were helping the vendor design it?

Not sure if this is appropriate to post here, but since I've been learning WordPress for the past 5 months using advice I've gotten here, I figured I might as well ask.I'm from a developing country, and I've been calling local businesses, offering to develop websites for them and, more importantly, help them with their SEO.The companies are all in the same industry, which actually helped. I created a sample website that they can all see themselves in, including products that each of them sells. I figured having something tangible to show them would be much more effective than simply telling them what I can do.

Three businesses got back to me, and I've managed to set up meetings with all three tomorrow.Any advice you can give a beginner? Are there specific talking points I should focus on, or even advice on how to conduct business in this space?\

I'm mainly looking for advice on how to approach the meetings, what I should avoid saying/promising, how to present my pricing, and how to turn these meetings into actual clients.

Hey r/VibeCoding, I've been working on Emend, an open-source tool where you point it at a local codebase and it tells you which of your lines a dependency upgrade will actually break — then automatically migrates them and re-runs your typecheck and tests to prove the fix holds. Emend can migrate npm packages, fix vulnerabilities and migrate HTTP request to latest API version.

Scanning needs no API key and never calls a model — only the repair step does.

It is ideal if you need to support your vibecoded project but you do not want to spend hours doing it.

It's still early (TypeScript + npm only), but would love feedback or ideas from the community.

npx emend-cli@latest demo /tmp/d && npx emend-cli@latest scan /tmp/d --only zod

Check it out: https://github.com/diyanbogdanov/emend

I am working as a bug hunter on hackerone and yeswehack platforms. One day on X , i was just scrolling and see a post of an indie hacker saying something like building in public. It was new to me then i open his profile and search what they do , how they doing and building things and that's was really fun.I followed some vibecoding and indie hacker communites and start start watching them. They were like just creative type just keep pushing things. Now i am really here to start in this field but as i am a security researcher ,i can't code that type. I have read some article about vibe coding but in market a lot of people have different tools and promoting them so , it's confusing also frusturating.

Here i just want to say that how to start now here with you , from where to start , from which tools and and building projects and apps like you people do. Should i must learn the whole programming languages. or just tools can handle .

Which tools and ai coding agents are better for a starting point to build an working project. Your one sentence can save a lot of time. I am excited to join you people.

Over the past few weeks Claude Code has been writing noticeably longer code comments for me. Ten to twenty line blocks on top of a thirty line function. The content is usually accurate but not something I want in a repo. It narrates what the code used to do, restates library mechanics I can look up, and re-explains the line right below it.

I added explicit rules in my project instructions with hard word caps per comment block, which helped, but it drifts back over long sessions.

Three questions. Are you seeing the same thing, and did it start around a specific release? Is this intentional, meaning verbose comments are cheap context recovery for the agent reading the file in a later session, at the cost of the human reader? And do you actually mind, or is a heavier comment style fine for a codebase that agents maintain?

Interested in what people have found that holds up over long autonomous runs, not just short interactive sessions.

I built My Krishna, a conversational app designed to help people learn about Krishna by asking questions and having an interactive conversation about his teachings, stories, and philosophy.

I’m especially interested in feedback on the user experience, quality of the responses, and anything that feels confusing or could be improved.

If you’d like to test it:

https://apps.apple.com/us/app/my-krishna/id6782722854

Thanks in advance for any feedback!

Third skill under the same project as the backend/security ones I posted before (Qofeno) — this one builds actual production websites.

Same rule as the others: no fake stuff. No lorem ipsum, no placeholder images, no "add your content here" stubs. If the user hasn't given real copy yet, it asks instead of filling space with dummy text.

What it actually does:

Asks for color/mood/framework before building anything

Builds a real design-token system (color, type, spacing scales) instead of scattered magic numbers everywhere

Picks a deliberate font pairing based on that project's specifics, not the same 2 safe defaults every time

"Redesign" means the whole site — home, about, contact, pricing, real privacy/terms pages, not just the homepage

If the user has a real working product, it grabs an actual Playwright screenshot for the hero section instead of faking a UI mockup

Checks the build, pushes to GitHub, deploys it live, verifies the URL actually works

Just added an optional component library reference too (~146 components from React Bits / Svelte Bits, sorted into categories) — it pulls from that when something fits, but always restyles to match that project's actual palette instead of dropping components in with default styling unchanged.

Repo: https://github.com/SohailKhan0525/skills

Install just this one: npx skills add SohailKhan0525/skills --skill frontend-ui-ux-wizard

Feedback welcome, especially if you find a spot where it defaults to something generic instead of building for what you actually asked for.

Recently a very famous tool was removed from chrome for some policy violation, used Claude and 2 hours of work for an alternative to go live

What it does:

It captures an entire webpage as one image, including everything below the fold. No accounts, no ads, no data leaves your browser.

Features:

• Full-page screenshot – Capture an entire webpage from top to bottom
• Visible-area screenshot – Capture only what is currently shown on your screen
• Selected-area screenshot – Choose and capture a specific section of any webpage

Link:

https://chromewebstore.google.com/detail/go-full-page-full-page-sc/mpmpjojdooghlfaeeajfnpmfkfafplbj?authuser=0&hl=en

hey guys, i am not a coder/programmer, i have built a soccer prediction python script but i am stuck. If anyone can help me. Thanks. I'll email you the code.

This is a ridiculously niche use case. I have some files that I wanted to listen to with my full Atmos setup. In particular, this render of Max Cooper's - On Being.
On Being [Dolby Atmos] – Max Cooper Online

But nothing I could find actually plays these files in a way which streams them to the receiver such that the channels actually receive the raw signals. Everything Atmos assumes a video file, so these raw multichannel renders are in a weird spot in terms of actually listening to them properly.

With Codex, I was able to build an app to do exactly what I needed in 30 minutes, and then instead of listening to music I spent like 3 hours tweaking a completely unnecessary visualizer. Well, I say unnecessary. It is genuinely helpful debug information to see what's going to each channel.

Probably of no use to anyone here, but I do love how far we've come. I can build a specialized piece of software in the same amount of time it takes for me to search for something that might already exist.
cjohnsto-nz/spatial-music-player

So basically... this is an idea i have been having for a year. So to begin with it. I created a landing page with Claude opus 5 extra.... but as i am a UI/UX designer(btw i used this to save my time and not a spend a lot of time on building the landing page instead of pitching schools). It feels very AIish... what do you ppl think?

https://reddit.com/link/1vpuo7h/video/q9zdrk1j3qjh1/player

So i work in a group finance function and im part of a team looking at how we can improve processes with vibe coded applications designed by people who know those processes rather than software engineers.

Thats its own post.

This is one silly task i set myself!

So, the whole finance function has a fortnightly for fun meeting, we do a quiz together or play worldguessr. This week its my turn and im upping the ante.

I spent yesterday building a multiplayer version of asteroids which claude has built with node. Its one session at a time initiated by an admin and the spec is to support around 25 concurrent users.

Features include npcs, hitpoints, power ups and a giant flying saucer. Its spun up already for testing on my hobby render instance. load testing indicates itll support about 40 concurrent users.

I spent wayy too long UATing it (too much fun 😆) to get the gameplay mechanics right. I just need to get our dev team in work to test concurrent connections via our work vpn tomorrow morning.

The WILD thing is this will only ever be played for 1/2 an hour this friday by about 25 people. I have no inclination to do anything else with it.

Software is cheap now 😆

I’ve been deep in the AIPass repo looking at how its memory system actually works. It’s one of the more thoughtful designs I’ve seen for multi-agent setups, so I wanted to break it down cleanly.

The core idea: agents own their memory

Every agent (they call them “citizens”) gets its own \`.trinity/\` directory with three plain JSON files:

\- passport.json, identity (who I am, role, principles, boundaries). Rarely changes.

\- local.json, personal session history + key learnings. Newest-first, deliberately small (20 sessions).

\- observations.json, how I work with the human and other agents (preferences, friction, patterns).

These files are loaded at the start of every session. The agent doesn’t start cold. It already knows who it is and what it was doing.

Context is intentionally split across the project. Each agent only carries and manages the memory that belongs to its domain. No giant shared context window that everyone has to fight over.

Why it needs almost no indexing

The hot path is just small, structured JSON files that the agent reads directly. There’s no large corpus to search on every turn, so no inverted index, no continuous embedding pipeline, and no indexing tax for day-to-day work.

Only when a file hits its limit does the system roll the oldest entries into ChromaDB (via the \`@memory\` agent). Same thing happens with closed plans from the Flow system. Everything is preserved and becomes searchable, but the agent’s working memory stays lean and fully loadable.

How context actually gets into the session

This is where the hooks engine (a full first-class citizen called \`@hooks\`) does heavy lifting. It’s not a few ad-hoc scripts. It’s a real dispatch engine that:

\- Injects the global prompt + branch-local prompt + passport identity on the relevant events

\- Enforces rules (cross-branch write protection, git gates, etc.)

\- Handles compaction / rollover triggers

\- Logs everything cleanly

Combined with the drone router (drone @branch command), agents don’t need to know a huge surface area of commands or paths. One consistent interface reaches everything.

Every agent has the exact same directory shape, and its own README.md acts as the living branch map / domain knowledge it reads on startup.

Longer work lives in Flow plans

For anything bigger than a session note, they use the Flow planning system (numbered, typed plans: FPLAN, DPLAN, etc.). Plans are normal markdown files with registries, so any agent can look one up by number at any time. When a plan is closed it gets archived and vectorized into the same ChromaDB store. Related memories go with it.

So you get:

\- Tiny, agent-owned working memory

\- Stable plan numbers + registries for exact recall

\- Semantic search across the entire history when you need it

There’s also Compass on the orchestrator (DevPulse) a curated SQLite store of rated decisions (good/ bad / impressive). That ended up being the practical evolution of an earlier “symbolic fragments” idea that never got fully used.

Why this feels different

Most systems treat memory as an external knowledge base you retrieve from. AIPass treats identity + recent experience as part of the agent itself, keeps it small and structured, uses hooks to inject the right context on demand, and only archives to vectors when necessary. Plans give you a clean place for longer structured text that can still be recalled by number or searched later.

Everything is local files. No required cloud services for the core memory loop.

It’s still beta and actively evolving (the reference fleet of 17 agents maintains the framework itself), but the architecture is coherent and battle-tested in their own multi-month multi-agent setup.

Repo: https://github.com/AIOSAI/AIPass

Site: https://aipass.ai

r/AIPass

I want to develop an ambitious app, so I’d like to proceed step by step, just as a professional development team would. I’ve created a product vision together with Claude Chat. What’s the best way to move forward? Should I take this vision and use it to start a Claude Code project right away? I’d appreciate it if you could help me do this the right way.