joshuakcockrell

I’m working on Envelope. https://envelopebudgeting.com It’s a budgeting app that comes with a built in checking account and debit cards. Because your budget can actually decline card transactions it’s a very effective system for stopping overspending.

I’m currently migrating the codebase to Swift 6 and dealing with the new concurrency system.

They have the same movement as their equivalent chess pieces.

Why not? Just because the screen is so small? I’m sure the right mount could hold this on your dashboard without issue.

To save others the click: the article is just saying minimalism.com is for sale.

Existing discussion https://news.ycombinator.com/item?id=48554215

I'm working on Envelope. It's a budgeting app that comes with a checking account built in. https://envelopebudgeting.com Because the checking account is built in, you can assign real money to digital envelopes for bills, groceries, savings, and everyday spending, then spend from the money with built-in checking, debit cards, and envelope-based spending controls.

The idea is to guide spending before it happens, not just track transactions afterward.

I'm building Envelope, which is a checking account with built-in budgeting: https://envelopebudgeting.com It's like if Mint, YNAB, or Copilot was built into a bank account. The goal is to help people budget, spend, and save from one account, instead of using a separate budgeting tool, spreadsheet (yuck!), or cash envelope system. It does that by allowing users to get paid via direct deposit and then organizing their money into digital envelopes for bills, groceries, savings, sinking funds, etc. It's attached to a debit card so everything updates instantly and has individual or joint accounts.

I'm currently working on the paycheck prediction algorithm so Envelope can automatically determine how much needs to be set aside from user's paychecks so their bills are paid on time.

Someone needs to solve barbecue. The entire industry is based on feel and experience. Why can't a beginner replicate Franklin's brisket by following a recipe online?

It's probably because the main measuring instrument (a probe thermometer) doesn't provide any feedback about fat rendering, moisture, etc. Plus, every brisket cut has different fat ratios and thickness, which means a recipe can't guarantee identical inputs like bread baking. I'd love for someone to throw some over the top engineering & experimentation at this.

Cofounder at Envelope here. Yes, a well polished banking app is much easier to use for many tasks

- Push notifications within seconds of swiping your card - Frictionless to check your balance/budget/cards with bio auth - Mobile check deposit (as others here have stated) - Instantly locking/unlocking your cards - Budgeting built-in

If, to you, "doing online banking" means "sitting down at my computer and scrolling through the PDF statements on Chase's website" (I don't blame you, I've been there), then yes, doing that on a desktop is much easier. I'd encourage you to take a look at how far banking apps have come recently.

Envelope https://envelopebudgeting.com

It's a budgeting app I'm building for iOS and Android. It's an alternative to YNAB, Goodbudget, or Monarch, but the checking account and debit cards are built-in, so it avoids the unreliable syncing issues that make budgeting apps suck. It's named after the digital envelope system and helps you organize money into categories for bills, spending, savings, upcoming expenses, etc. Individual and joint accounts.

Right now I'm working on an upcoming paycheck detection system to automatically split your paycheck across your budgets.

Maybe there are some cool AI-centric games that I’m overlooking?

The enemy locomotion in Arc Raiders was almost entirely created with reinforcement learning. It’s a very impressive modern example (the game has been out for less than 6 months).

Here’s the documentary explaining how the RL locomotion works. Skip to 10 min 36 sec. https://www.youtube.com/watch?v=DRlhpzc7ImA&t=636s

Lately I’ve been interested in how budgeting apps model cash flow over time. A lot of tools are either expense trackers or monthly budgets that assume clean month boundaries, which breaks down quickly if you’re paid biweekly or irregularly.

Envelope budgeting (the method) works by allocating money up front so future obligations are actually covered before spending happens. But the hard part is handling income timing and paycheck variability without overfunding the future.

Anyways, I’m currently adding a cash flow detection algorithm to Envelope (the budgeting app) https://envelopebudgeting.com that only allocates paychecks to obligations before the next paycheck unless future funding is strictly required. That approach has avoided a lot of timing edge cases I kept running into.

https://joshcockrell.com

I’m building a budgeting app called Envelope, it’s like the envelope budgeting concept but has the checking account built in. https://envelopebudgeting.com

I'm building Envelope — a banking product purpose-built for envelope-style budgeting.

Most “budgeting banks” (Ally Buckets, Wells Fargo Budget Watch, etc.) bolt budgeting on after the fact. Envelope was designed from day one as an integrated budgeting bank account. The checking, savings, and debit cards are all built around real-time envelope balances.

Each envelope acts like a dedicated account with its own balance and optional virtual card. Spending directly from an envelope means your budget is always accurate — no syncing, no spreadsheets, no “catch-up” categorization. Everything runs on-ledger with automatic spend-locking and instant visibility.

We’re a small YC-backed team (former Robinhood and Apple Card team members) focused on rebuilding personal finance from the ground up to be simple, and transparent https://envelopebudgeting.com

I’m currently 4 years in to doing everything possible to build the best budgeting app https://envelopebudgeting.com

This week I’ve been working on predicting upcoming paychecks with Nodejs so we can automatically decide how much funds to move into your budgets when you get paid. I pull the past 3 months of transaction data from our Postgres database using Prisma and run some analysis.

People think syncing and delayed transaction data is normal, and I’m working on changing that by having the budgeting built in to the checking account. Along with a high yield savings account, goal envelopes, bill envelopes, etc, joint accounts, etc.

A budgeting app that comes with a built-in checking account https://envelopebudgeting.com/

Currently trying to convert the SwiftUI app to Compose using Skip.

Have you scrolled through the Switch store? The UI freezes for seconds at a time while network requests lock up the main thread.

I worked on the Twitter iOS app. Can confirm my kid isn’t allowed a phone until they’re a teen. Once they get one, I’ll be spending hours figuring out how to MDM brick the thing so they can’t get anywhere near social media.

Having said that, I’m still an app dev (personal finance & budgeting) and I’m excited to onboard my kid into that world.

This is my biggest issue with Prime Video. You never know what's included and what costs extra.

I bought a used Apple Watch for sleep tracking for $230. It took a few days to get used to sleeping with a watch on but I have a 1.5 yr old daughter and it’s been a game changer to quantify how much I’m waking up for her and how my nightly routine impacts my productivity.

There are apps in the App Store that give you a sleep score.

JavaScript needs a Python 2->3 moment, but like 100x the damage

Sure there's more money in the Western app ecosystem for iOS apps, but that doesn't mean your app should inherently cater for iOS first

That's exactly what it means. When I was at Twitter, the Android app generated 1/10th the revenue of iOS. If you care about building a business that generates revenue, you should definitely cater to iOS first.

What’s wrong with making cosmetic changes solely to improve low self esteem?

I just already had a graphql backend, which uses the gql schema to codegen the networking layer.

Probably not much different from an open-api schema + codegen, I just had it set up so it was an easy choice for me shrug

We picked Kotlin libraries that supported KMM. So we used Apollo Kotlin, and our network requests were handled by that library's KMM translation. So there was a layer of abstraction we accepted. We never wrote raw `HttpURLConnection` code on the Kotlin side, so I'm honestly not sure what that would get translated into. KMM compiles your code into an iOS framework, so you don't actually get to see the code it creates for you (you get access to the Objective-C headers).

You're totally right, you're at the mercy of these KMM libraries and their knowledge of platform specific optimizations.

I've been using Kotlin Multiplatform Mobile (KMM) heavily for the past 2 years on my current YC startup. I'm in the process of removing the entire thing.

KMM is an alternative to cross platform mobile libraries like Flutter, React Native, etc. The idea is that we could write all of our mobile app's business logic, networking layer, and caching layer in Kotlin, and KMM will codgen the matching iOS code. "We only need to write it once!" is the selling point. Then we get a blank canvas to build our UI using 100% native SwiftUI & Jetpack.

In reality, the codegened iOS code gets you 90% of the way there, the but extra 10% is extremely frustrating to work with. Enums (Sealed Classes in Kotlin) get mangled in translation and you lose exhaustive switch statements. Basic data types like Bool and Int get wrapped so you can only access them using additional .boolValue or Int64(..) constructors. Entire companies are being built around solving the pain point of this last 10%: https://touchlab.co

In my opinion, the fatal mistake the KMM team made was designing it to support Objective-C, instead of just Swift. So you're using a Kotlin layer -> mangled through Objective-C -> accessed from Swift. It's a confusing decision, as the only iOS teams still actively using Objective-C are legacy apps (like the Twitter app), which seems like the opposite target market for new mobile tech like KMM. Kotlin and Swift are both modern languages, and my gut says the interop between the two would be much better without Objective-C in the middle.

Further discussion from Droidcon if you're interested: https://www.droidcon.com/2022/08/01/sdk-design-and-publishin...

As you progress beyond "POC" to integrating and shipping real production code, the design of the "SDK surface" becomes more complicated and nuanced (or, possibly, problematic)... An Android consumer can see all the richness of the Kotlin language, but the iOS side gets filtered through Objctive-C into Swift. Much can get lost along the way.

P.S. I'm replacing KMM with the Apollo Kotlin and Apollo iOS SDKs, which codegen your app's entire networking/caching layers. So it solves the same pain point (aside from business logic), but in a much cleaner way!

I’m currently building this at envelopemoney.com

I make all the beats for my YouTube vlogs. I post the songs for others to use royalty free. Some have several thousand plays.

https://youtu.be/JhQpXwXUWok

I got married ~3 years ago after several years of dating around. This book really helped me understand the psychology of finding a partner and getting married

Love Factually - Duana Welch, PhD

It talks a lot about playing hard to get. The book basically frames it in the same “more in demand” that this linked article talks about.

And also adds something I’ve always remembered.

We see hard-to-get as attractive because we know, for others, they will be impossible-to-get once they’re our partner.

(I’m paraphrasing)

So hard to get only works as long as we perceive they’re hard to get for others also.

Anyways, that book was definitely a life changer for me so if you’re interested in this kind of stuff or trying to understand the confusing world of finding a partner I highly recommend it.