u/JasonReed1

I've been at Finnish for a year and a half, and only recently caught something I probably should have picked up much earlier. For maybe the first six months, whenever someone asked me a yes/no question, I answered kyllä. It felt safe. Textbooks call it "yes." What I eventually noticed is that Finns around me almost never do that.

The default is to echo the verb. Someone asks Tuletko? and the reply is Tulen. Not kyllä tulen, not even kyllä on its own. Just the verb, put in the right person. Puhutko englantia? Puhun. Asutteko Helsingissä? Asumme. Linguists call this an "echo answer," which sounds more technical than it is. Sitting across from someone, it just sounds like they answered your question with half a sentence.

The first mistake I kept making was copying the ending back. Someone would ask Tuletko?, and I'd say Tulet, which is grammatical Finnish, except now I'm telling them that they are coming. You have to switch the person: their tuletko is asking about me, so I say tulen.

Once I started listening for kyllä, I realized it does show up, but it's doing something specific. It's emphatic. It's the "yes I did lock the door" kyllä, the "yes I will be there, don't worry" kyllä. And it's what you need after a negative question. Etkö tule? Kyllä tulen. If you say joo there, it sounds like you're agreeing with the negative. That reversal is the one place kyllä isn't optional.

I got most of this from a language partner I've been messaging on HelloTalk who lives in Tampere. I sent her a voice note with three example exchanges I'd been unsure about and she recorded herself answering each one the way she actually would. After that, kyllä stopped feeling neutral to me.

Still don't have a clean feel for joo versus juu, or for reading jaa without assuming it's a yes.

Some context. I collect watches, mostly Seiko and Hamilton stuff, nothing crazy, and picking one in the morning is my main hobby.

Two years ago I got an Apple Watch to track sleep and general health. Wore it for a few months. It's a good product, that's not the issue. The issue was every morning I'd stare at my drawer and pick the same slab of aluminum instead of any of my watches. Sold it.

Went back to normal rotation. Kept feeling like I was missing the health data thing.

Tried Oura briefly, ring caught on stuff since I work with my hands. Considered Whoop but couldn't get past the subscription. That's when I found the "no display" band category.

Ended up doing double-wristing. Mechanical on the left, screenless health band on the right. Three months in, honest thoughts.

Anything with a screen ruins the setup because now you've got two "watches" competing. Screenless disappears. Nobody notices unless they're looking.

Right-wrist adjustment took two weeks of banging the sensor into doorframes and my mouse. Then it faded.

Data got more interesting once it wasn't glanceable. On the Apple Watch I checked constantly and it stressed me out. Now I open the app every couple of days and actually look at trends instead of live HR.

Battery is why it works. If I had to make a charging decision every day I'd give up. The one I ended up with runs about two weeks so I plug it in on some random Sunday and forget.

Fair warning if you're considering this: it does not solve wanting notifications on your wrist. I realized I don't actually want those anywhere, so it worked out for me. Might not for you.

Anyway. If you love watches and keep circling the health tracker question, double-wristing is a real answer. Would've saved me the Apple Watch detour if I'd known.

Been listening for years. Peter's done deep dives on basically every longevity molecule at this point. NAD/NMN/NR, rapamycin, resveratrol, metformin, taurine, klotho, urolithin A. Even the more speculative stuff usually gets a fair look.

One thing I keep waiting for, and it hasn't come up: ergothioneine.

Bruce Ames put it on his "longevity vitamin" shortlist in that 2018 PNAS paper, alongside taurine and PQQ and the carotenoids. His argument is basically that some nutrients aren't strictly needed for survival, but their chronic deficiency quietly wrecks long-term repair. Ergothioneine fits the pattern pretty well. Humans can't make it, we have to eat it (mushrooms are basically the only real source), we have a dedicated transporter for it (OCTN1/SLC22A4), and it concentrates in tissues that take the most oxidative damage.

Human data isn't huge but it's not embarrassing either.

There's the Singapore mushroom study (Feng et al. 2019, n=663) where people eating more than 2 servings per week had roughly half the odds of MCI. A separate 470-person memory clinic cohort out of NUS followed for 5 years showed low baseline plasma ergothioneine predicted cognitive and functional decline. And there's a small MCI pilot from 2024 (25 mg 3x per week for a year) that showed some RAVLT improvement and stabilized neurofilament light chain. Only 14 per arm after attrition though, so take it with a grain of salt.

The thing that really got me was that April 2025 Cell Metabolism paper from Spiegelman's lab at Dana-Farber. Sprenger et al. They did a MITO-IP screen on exercise-trained mice and found ergothioneine accumulates in muscle mitochondria with training. Then thermal stability profiling to pin down the direct molecular target, which turned out to be MPST (3-mercaptopyruvate sulfurtransferase). MPST makes H2S and pyruvate. EGT binds it, activates it, boosts mitochondrial respiration. Feed WT mice ergothioneine and endurance goes up. Do the same in MPST knockouts, nothing happens.

That's the kind of story Peter usually eats up. Direct target, KO validation, physiological readout tied to exercise adaptation, from a lab that's not messing around.

Rhonda's covered it a few times on FMF (Q&A #53 in late 2023, and Aliquot #106 with taurine and PQQ). So it's not totally off the longevity podcast radar.

I can guess why he hasn't gotten to it. Human RCT data is probably still too thin for his taste. Optimal dose for a healthy person is genuinely unknown. And it doesn't have NAD-precursor money behind it, so nobody's really pushing him to talk about it.

But the thing I keep coming back to is that he'll entertain rapamycin off-label based on mouse data plus mechanism, and here's a compound with a cleaner safety profile, an identified target, and at least some human cohort work. Even a brief AMA answer would help me calibrate. Barry Halliwell out of NUS or Spiegelman himself would be a great guest for a real episode.

Just feels like the biggest gap in the coverage right now.

We're a 10-person SaaS team in Singapore and I've been staring at our July P&L trying to figure out what to do about our AI infra spend. Combined API bills across OpenAI, Anthropic and Google plus Cursor seats, Perplexity Pro, GitHub Copilot for the team, and one seat of Claude Max for our lead engineer came to about SGD 18,500 last month. That's now our second biggest line item after payroll and it's growing 15 to 20% month over month.

The AI cost itself I mostly understand and can model. There are decent playbooks now for cutting API bills 50 to 70% through model routing, cached input, batch API for non-realtime workloads, and picking cheaper models where quality allows. Ramp launched an AI Token Spend Management product for exactly this in July, though it's US-and-Canada-only right now and doesn't cover an SG entity yet.

What I hadn't fully modeled was the payment stack cost sitting on top of the raw API rate. Almost all AI providers bill USD to US Stripe merchants. Our stack for this is Aspire for the SGD operating account and a separate USD balance on Airwallex where we receive from our US clients. The Aspire card gives 0% FX on the first SGD 13,000 a month on the Premium plan, but AI bills concentrate in the first half of the month so we typically burn through that allowance by mid-month, and everything else hits 0.4 to 0.6% FX for the second half. Airwallex is a similar shape once you're past what your USD balance covers.

Between the FX drag, the occasional decline on a cross-border charge that costs an hour of engineering time to fix, and the fact that Aspire Yield on our USD balance is around 3.45% while the AI bill is silently compounding, the net effect is meaningful. Not huge in absolute dollars at our size, but the trend line is bad.

I've been circling three directions and none of them feel obviously right.

The most conservative move is to just size the USD balance up so more of the AI spend happens FX-free out of a currency we already hold, and route more revenue collection through Airwallex to build that balance faster. Boring and probably correct for now, though it means idle USD earning around 3.45% rather than being deployed anywhere else.

The more aggressive move is to route the AI spend through a stablecoin path. A few SG founders I know have started splitting their AI spend so recurring subs go on a self-custody stablecoin card that spends USDC directly with no FX conversion, and the metered API spend stays on the SGD business card where accounting is cleaner. Bleap works for the subs side if you're in the EEA, though not for us as an SG entity. BenPay Delta is the one I've been evaluating specifically, mostly because the multi-chain USDC top-up means we can move stablecoin in from wherever we happen to hold it, and their explicit AI-subscription payment support covers ChatGPT, Claude, Perplexity, Midjourney and OpenAI API among others. Two things worth flagging on the product itself. They added a $1/month account fee starting August 4 that wasn't there before, so a lot of older comparison threads still list it at zero monthly. And country coverage on the account-opening side is narrower than the EU-EMI options like Bleap because they're on a US-MSB path rather than EMI, which is a real thing to check for your specific setup before routing material spend through it. The flaw is you're then holding operational cash in stablecoin, which puts you outside the MAS-regulated stablecoin perimeter since the SCS framework only covers SGD and G10-pegged issuers based in Singapore anyway.

The third direction is a gateway like MixRoute or TokenMix that routes to Anthropic, OpenAI and Gemini through one endpoint funded in USDT, with zero markup on provider pricing on the ones I've looked at. One bill instead of five. Obvious concentration risk if the gateway goes down or gets deprecated by a provider though.

Not making a decision this month, mostly want to hear what other AI-heavy SG founders are actually doing. The finance side of this is starting to matter more than I expected six months ago. If you've stayed on the vanilla Aspire/Airwallex/Wise stack and found it works fine at higher spend, would like to hear that too. Also open to being told the yield-vs-FX-drag question isn't worth solving at our size and I'm overthinking it.

Been learning Polish for around 18 months. Finished Krok po kroku 1 last winter, halfway through book 2 now, maybe 2500 words on Anki. Cases I can survive most of the time. Aspect pairs still trip me up but I can usually pick something. Reading polskieradio.pl is doable if the topic is familiar.

Started doing weekly video calls with a Polish friend around a year in. Met her on HelloTalk during a stretch when I was in "I need to actually speak this before I completely lose the ability" panic mode. She's a graphic designer in Wrocław, wanted to practice English, so we swap thirty minutes each. She's not a teacher and mostly can't explain why things sound wrong. She just goes "mmm nie" and pulls a face.

The thing that took me way too long to see was diminutives. Krok po kroku introduces them somewhere in book 1 with the standard framing, kot → kotek, dom → domek, small or cute or affectionate. I learned the suffixes, filed them in a mental drawer marked "for pets and kids," and moved on.

Then I went to Kraków for a week in spring. Ordered coffee at a place near the Rynek and said "poproszę kawę." Grammatically clean, accusative, the whole deal. Barista gave me my coffee and I noticed the person behind me ordered "poproszę kawkę." Went to a bakery the next morning and heard people asking for "chlebek" and "bułeczkę." Nobody in three days ordered anything in the plain form.

Asked my friend about it on our next call and she laughed. Said "poproszę kawę" is completely fine and polite, poproszę already does that work. But locals almost always add the diminutive on top in casual places, and skipping it makes you sound like you're reading from a phrasebook. "Kawka" or "kawusia" isn't about the coffee being small, it's about you not sounding stiff. Her grandma orders "herbatka" not "herbata," her mom emails work colleagues asking if they have "chwilkę" not "chwilę," and if you say "podaj chleb" at a family dinner instead of "podaj chlebek" you sound weirdly cold. Same content, different social temperature.

That reframing broke something open. Once I noticed it I could not stop hearing it. Waiters going "sekundkę" instead of "sekundę," my friend's mom offering "kanapeczkę" at lunch, someone on a work call asking me to wait "chwileczkę" while she pulled up a file. It's not baby talk. It's the default polite register for anything transactional or friendly, and skipping the diminutives in those contexts marks you as an outsider even when your grammar is otherwise fine.

You can also overdo it. My friend said if I ordered "kaweczkę" or "chlebeczek" I'd sound like I was being cutesy or joking, and there's a whole layer of which diminutive fits which register. Kawka and kawusia and kaweczka aren't interchangeable, they sit on different spots between neutral-polite, affectionate, and joking. Nobody really teaches you that map. You pick it up by listening to what people actually say and adjusting until nobody makes a face at you.

Kind of curious what other register stuff people ran into.

Been running finance for our APAC region out of Singapore for a few years, six countries reporting up. Wanted to share something that's been eating my headspace this year, in case anyone's hitting the same walls.

Short version: three of our biggest jurisdictions are all in different phases of e-invoicing mandates, they don't interoperate, and our AP and expense pipeline was the first thing to buckle. Not AR, which is where I initially expected the pressure.

Where the three markets sit right now

Singapore is on InvoiceNow, IRAS's Peppol-based network. Mandatory for newly incorporated companies with voluntary GST registration since November 2025, all new voluntary GST registrants since April 2026. Committee of Supply 2026 confirmed existing businesses roll in progressively from April 2028 to April 2031, notified individually by mid-2026 based on annual supplies. Format is PINT-SG. GST at 9%, unchanged in Budget 2026. Over 63,000 businesses already on the network per IMDA. Big MNCs are in the last wave, but many voluntarily-registered suppliers are already transmitting.

Malaysia is on MyInvois via LHDN. Phase 1 (>RM100m) August 2024, Phase 2 (RM25-100m) January 2025, Phase 3 (RM5-25m) July 2025, Phase 4 (RM1-5m) January 2026 with relaxation extended to 31 December 2027. Phase 5 was cancelled by the PM's 7 December 2025 announcement, exemption floor now RM1m. The change that matters most for AP in 2026: individual e-invoices are required for any transaction above RM10,000. No more monthly batches for those.

Indonesia is on Coretax. DJP switched over from e-Faktur in January 2025 and full enforcement kicked in 31 December 2025. From that point, DJP clearance is a legal precondition for a valid VAT invoice, not a post-hoc check. Uncleared invoices don't support the buyer's input tax deduction. Only large taxpayers issuing 10,000+ invoices/month can still use e-Faktur Desktop or H2H channels, and even those feed the real-time validation. Coretax generates the invoice serial number now, not the seller, and buyer identity data auto-populates from DJP's registered database.

Three platforms, three rollout schedules, no interop between them.

Why AP got hit before AR

When you're the seller, you control the systems and adapt to one platform at a time. When you're the buyer, you receive whatever suppliers send. SG suppliers push PINT-SG structured files via Peppol, MY suppliers send MyInvois-cleared PDFs plus underlying JSON, ID suppliers send Coretax-cleared PDFs with auto-generated Tax Invoice Serial Numbers. The SSC has to ingest three different structured formats and reconcile against three different clearance registries on top of PO-matching.

Employee expense is worse. Jakarta ride on a Coretax-registered platform, KL client lunch that crosses the RM10,000 threshold and now requires MyInvois clearance at point of sale, SG hotel stay from a voluntary-registered supplier who's newly on InvoiceNow. Each has different validation, retention rules, and consequences for input tax recovery if you miss it. T&E policy has to be updated country by country.

What we've tried and where we've landed

We started with "extend the existing regional AP platform". SAP Concur has the breadth but their InvoiceNow support was still catching up when we scoped it and Coretax H2H was on a 2026 H2 roadmap. Payhawk works well for the European travel our parent handles centrally but APAC localisation is thin if ID and MY are your compliance load. Country-specific tools cover one market at a time and don't consolidate cross-border.

We landed on Helios for the ID and MY entities. It's Singapore-based, and its local tax integration for those two markets was already live rather than roadmapped, which was the tiebreaker given how tight the ID Coretax cutover window turned out to be.

Setup ended up hybrid: existing regional AP platform for SG and TH where timelines are further out, the more localised layer for ID and MY where mandates are already biting. Not elegant. Two vendor relationships and some double-handling for cross-entity transactions. But we're actually compliant this quarter.

Where AI helps and where it doesn't

Rule 3 tells me to keep this concrete, so only what we're actually running:

OCR and structured extraction on the receipt/invoice ingestion layer, especially long-tail merchants who aren't in scope of any mandate yet. GL mapping across country-specific chart of accounts, which is where errors used to accumulate. Flagging likely T&E policy exceptions before submission rather than at approval, which shifted the reviewer workload significantly.

Where it doesn't help: at the clearance layer, because tax authorities are the authority not the model. Cross-entity FX and intercompany logic still gets human review because the same transaction can carry different tax treatment in two entities. Close and consolidation are still hands-on where audit trail specificity and sign-off matter more than throughput.

The J.P. Morgan 2026 APAC CFO survey number (44% using AI for data analytics, only 7% in risk and compliance) tracks with what we see. Reshaping the ingestion and mapping layer is real. Reshaping the compliance decision layer isn't.

What I'd tell someone setting this up now

Don't build for the endstate. It keeps moving. SG endstate isn't in until 2031. MY Phase 4 relaxation pushed out from mid-2025 to end of 2027. ID Coretax has already had operational adjustments (PER-11/PJ/2025 moved the upload deadline to the 20th of the following month, the 8 November 2025 Desktop-Coretax desync broke certain AP matching flows). Build for the current phase, keep regional and country layers loosely coupled, stay on top of the next-phase notifications.

Vendors selling a "single platform for all APAC compliance" underdeliver in at least one country. The AP and expense layer, where regional consolidation and country clearance meet, is where the ROI on getting it right is highest.

Been at Korean for about 16 months. TTMIK Level 5 and most of 6, maybe 3k words on Anki, reading webtoons okay-ish if I have a dictionary. Test-type grammar is fine. Speaking is where I fall apart.

Started doing weekly video calls with a Korean friend I met on HelloTalk sometime around month 10. She's not a teacher or anything, just a designer who wanted to practice English, so when I ask her why something is grammatical she usually just says "우리는 그렇게 말해요" and shrugs. Which is actually fine, most of the time.

One thing I kept getting stuck on was -잖아요. She'd end sentences with it all the time and I would kind of nod along without really knowing what it did. My lessons hadn't gotten there yet, so I just filed it under "ending I hear a lot" and moved on. When I finally tried it in my own sentences she'd give me this look like the meaning didn't fit.

-잖아요 isn't really asking a question. It's flagging that the listener already knows the thing you're saying, or should know it. Like when your friend says "I told you yesterday" and there's this whole layer of "you already have this info, I'm just reminding you." That layer is what -잖아요 carries. If you use it wrong the sentence sounds weirdly presumptuous, like you're insisting the other person should already know something they don't.

Once I got it I started hearing it everywhere. My friend saying 비 오잖아 when it was pouring outside the window. Somebody in a drama snapping 제가 말했잖아요 to a coworker. It's not a niche grammar point. Native speakers use it constantly, and once you catch it you realize how much of the conversation you'd been half-following.

Took me a while to realize you can't really Anki your way into it. You have to hear it enough times in real context that your brain stops translating and starts feeling when it fits. Still mess it up sometimes. But at least now I know when I'm messing it up.

Two skylights in the great room, vaulted ceiling, one south facing and one east facing. Reached them with a hooked pole for years and gave up around march when I admitted I was never going to run the summer routine on my own. Installed motorized shades early may, so four months of real use now.

Went with the smartwings skylight cellular in blackout, matter over thread, solar charged since I wasn't going to climb up there with a USB-C cable every few months. There's no proprietary app so pairing goes straight into home assistant over matter, apple tv 4k handles the thread side. The four-sided aluminum frame is what actually made install work on the sloped ceiling, standard cellular kits would have needed a bunch of shimming.

VELUX would have made sense if I were replacing the skylight units too, but the units are fine and their standalone shade kits don't do matter, which would have meant living in their own remote and rain-sensor system. Yoolax and a couple of custom shops didn't do a skylight-specific frame with a matter-native motor, so it kept coming back to the same one.

Hardware side is done. The part I keep rewriting is the automation, and every version so far has been dumb in a different way.

First pass was solar elevation based. Close both when the sun clears 55 degrees, open when it drops back under. Made sense on paper. In practice the great room turned into a cave from 11 to 3 and my wife pointed out that we now had skylights that were covered during literally the only hours skylights do anything.

Second pass tied it to a temp sensor, only fires above 79. Better in shoulder seasons but the sensor is 12 feet up and lags well behind the actual comfort in the room, so by the time it triggers we've been baking for 20 minutes, and once they close the sensor cools off fast and they reopen while the room is still warm. Added a for: 15 minutes debounce, helped a little, not enough.

Now trying partial position instead of full close. 60 percent down at peak sun and warm inside, so you still get diffuse light but block the direct beam. Feels less dumb but the shades micro-adjust more than I'd like and I'm quietly worried about motor cycles over a few years.

Winter is the other thing I haven't figured out. Skylights are the biggest heat loss point in the room after sundown, so there's a case for closing at night for a bit of insulation. But then we lose the morning light through them, which was half the reason I liked them. Feels like there's a heating-degree-day condition that needs to be in there somewhere and I haven't wanted to open that box yet.

Curious how other people handle the block-the-sun-without-defeating-the-skylight trade off. If you're running a partial position schedule that feels good day to day, would like to see how it's structured. Otherwise I might just cave to time-of-day and stop trying to be clever.

Been running about 60% of my daily spend through a self-custodial stablecoin card for the last four or five months and something happened last week that made me realize I hadn't thought this through as carefully as I thought.

Ordered a piece of equipment from a smaller online store, item never showed up, seller went dark after a few emails. On a normal card this is a five minute call to Chase, chargeback initiated, done. With my self-custodial setup I paused for a second before realizing there was no equivalent path. The card is a physical Visa, transaction went through a normal Visa acquirer, but the money funding it came out of my own wallet and there's no issuer bank holding my funds to reverse things through.

This isn't a bug in any specific product, it's structurally what self-custody means. Traditional card chargebacks work because the issuer bank fronts the money and eats the loss during dispute, then claws back from the acquirer under Visa's operating regulations. When there's no issuer bank holding customer deposits (because the customer holds them), you can't reconstruct the same recourse structure.

The consumer protection framework everyone relies on without thinking about it (Zero Liability policies, FCBA and Reg E in the US, PSD2 in the EU) sits on top of that money flow. It's the invisible layer that makes "just use your card" the default for anything remotely risky. Strip out the issuer's financial exposure and the whole thing has to be rebuilt from scratch.

What's actually being built in that direction so far, from what I've seen: tx simulation and signing prompts at the wallet level (Rabby set the bar), on-chain merchant reputation attempts that never really scaled, a few products experimenting with insurance-pool style coverage for specific attack types like phishing. All of it is early and none of it functions like the "call the bank and get your money back within 60 days" experience that's been standard on cards for as long as most people have been using them. The self-custodial card I've been running for the crypto-native side is BenPay. Signing prompts and simulation are present at the wallet layer, but by design there's no chargeback path once a transaction is confirmed, and their country coverage under a US-MSB registration is narrower than a mainstream card program. Both are structural rather than product complaints.

The adjustment I made after last week is boring but revealing. Anything with higher dispute risk (subscription services from vendors I don't know, marketplace purchases, international stuff, honestly anything where the seller might just disappear) went back to a traditional card. The self-custodial card kept the categories where I trust the counterparty or where the transaction is stablecoin-native and dispute wouldn't make sense anyway. Two cards, two risk profiles.

Curious how the payments people here are thinking about this. Every projection deck I've read about stablecoin payment adoption talks about volume and settlement finality, but I haven't seen one with a clean answer for the consumer-protection layer Visa built up over decades. Feels like the biggest unsolved question in the category.

Comparto lo que me funcionó, por si a alguien le sirve.

The thing I actually use for speaking practice now is HelloTalk. Been on it about 5 months. Everyone there is a native speaker of some language learning another so exchanges are actually mutual, half the time I'm helping someone with English, half the time I'm messaging in Spanish, no one feels like they're doing anyone a favor. Voice notes are the piece that moves the needle on speaking, you record 30 seconds, they reply with one, you correct each other as you go. Text messages for reading and picking up phrases, voice notes for output. That's the daily loop.

First 6 months was pretty standard. Duolingo daily until it wore off, then Practice Makes Perfect for verb tenses because the subjunctive kept killing me, then Dreaming Spanish for input. Around month 7 I could read El País with occasional dictionary help and follow slower podcasts. Real-time conversation though, absolute joke. I'd mentally construct a sentence, panic about ser vs estar, by the time I had the verb out the conversation had moved on.

Realization was pretty obvious once I saw it. Apps and books had taken me as far as they were going to. What I actually needed was hours of low-stakes talking with people whose first language is Spanish, which no app really solves. You just have to find people.

Catch nobody warned me about: finding partners who are actually consistent takes work. I added maybe 15 people before I had 3 who stuck around past the first week. And you have to be a bit pushy about switching to Spanish or plenty of people will stay in English the whole time.

Also tried a couple weeks of paid tutoring before this and honestly the pressure of paying-by-the-hour made me worse. Kept flinching at mistakes because the meter was running. Free peer exchange where it's mutual took the pressure off, let me be bad at it for a while, which apparently was the actual bottleneck.

We raised Series A late last year and started building out sales and CS in KL and Jakarta around Feb. Right now maybe 14 people in SG, 6 in KL, 4 in Jakarta. The plan was to keep running on Spenmo for cards and expense since we've been on it from seed, plus the founders' Aspire for misc stuff. That worked when everyone was in SG.

Two things are breaking now.

One is corporate card reconciliation. We've got SG-issued cards, MY-issued cards for the KL team because some local vendors won't take SG cards without weird FX hits, and the Jakarta team is mostly running personal cards then claiming back because we haven't figured out a clean way to issue ID cards to non-residents yet. End of month our ops lead basically spends three full days matching what got spent against what we have receipts and approvals for.

The other is reimbursement timing. We pay payroll on the 25th and reimbursements were supposed to ride that cycle, but with the Jakarta personal-card situation we're routinely 2-3 weeks behind on actually paying people back. Two of the new hires have raised it in 1:1s already. It's more a credibility thing than a money thing, the amounts aren't huge but it makes us look like we don't have our act together.

I've looked at Volopay (similar shape to Spenmo, doesn't solve enough), Aspire's newer expense product (probably the easiest upgrade path tho I'm not fully sold), and the bigger ones like Concur which feels like overkill for our stage and budget. A founder I know who scaled into China and Japan after an acquihire ended up on Helios for the APAC entities while keeping their SG card stack separate, said implementation ran around 3 months and the APAC tax categorization needs some hand-holding for non-regional finance, but the multi-entity reconciliation pain went away. Brex and Ramp came up too but turn out to be pretty US-only once you dig in. Trying to decide if we just bite the bullet on a proper multi-entity reconciliation setup now or throw more people at the manual side for another 6 months.

Mainly curious how teams that have actually scaled across SG/MY/ID/PH are running this. Not really looking for the SG-only answer because we've been there.

Set up an mmwave presence trigger for my home office about three weeks ago and i'm running into a logic problem i can't crack. The idea was if someone's actively in the office between 1 and 4pm, keep the shades at 50% for glare control, and if the room reads empty, drop them all the way because that wall takes brutal afternoon sun and the AC was running nonstop.

Hardware is an Aqara FP2 on the ceiling, three SmartWings dual-channel rollers on the back wall, all stitched together in Home Assistant, only time i open the SmartWings app is when it pushes a firmware update.

Problem is the FP2 keeps reading me as gone when i'm just sitting still. Reading a long doc, deep in writing, on a call where i'm mostly listening. Hold time was at the default 5 min and last week i had three meetings where the shades dropped fully mid-call. One time the room went almost black, the only light was the laptop screen, and the person on the other end asked if my power had cut out.

Pushed hold time to 20 min, which helped with the during-call thing but broke the energy side of the logic. If i step out at 2:30 to make coffee, the FP2 still thinks i'm there for the next 20 min, shades stay half-down, room gets warm anyway. So i'm just shifting the bug around.

Also tried adding a cheap LD2410 mmwave board pointed at the chair as a second condition, AND-gated with the FP2. That solved the 'stepped away' half but introduced a new fail where leaning back in the chair was enough to drop me from the desk sensor while the ceiling unit was still seeing me, and i'd ping-pong between 50 and fully closed every couple of minutes which is somehow worse than the original problem.

What i'm stuck on is whether the answer is just adding a calendar condition (during meeting hours, hard-lock at 50% no matter what the sensors say) or whether anyone's actually solved the 'active sitting' versus 'left the room' distinction without layering three sensors. BLE presence with the phone as the source has come up but i'd rather not depend on the phone being charged on the desk.

Picked up a used commercial DMR portable at a surplus sale about two and a half years ago. It came with two OEM batteries that the previous owner had clearly cycled hard but they still held a respectable 14 to 15 hours of mixed RX/TX/scanning for the first 18 months I had it. I've been using it almost daily on 2m DMR, a couple of local repeaters and Brandmeister through a hotspot when I'm home.

Then sometime in late April one battery started dropping to about 6 hours, and within three weeks it was down to 4. The other one followed the same curve about two weeks behind. I've watched lithium packs age before but the speed of this collapse caught me off guard. Both packs felt completely normal until they didn't.

So I went into the aftermarket pool because OEM replacements for this model aren't cheap anymore and the few authorized dealer listings I tracked down were either out of stock or quoting 3 week lead times. Tried two so far.

First one was a 3300mAh listing on Amazon from one of those generic battery brands shipping out of a warehouse in NJ. Showed up looking visually identical to the OEM, same connector, same belt clip slot. Actual runtime got me maybe 11 hours under the same usage pattern that used to give me 14 on the original. Not 3300mAh of capacity by any stretch. The case felt a touch thinner too, the radio doesn't sit quite as flush against the clip.

Second one came from a US-based two-way radio parts reseller, slightly pricier, claimed 2500mAh and IP67 rated. Runtime was honestly close to OEM, maybe 12 to 13 hours, which I can live with. The IP rating claim is what bothered me. The OEM uses a sealed gasket on the contact face you can see through the housing. The aftermarket one has what looks like a similar gasket but the contact face is slightly recessed in a way the OEM isn't, so I'm not sure the seal seats properly. Haven't dunked it to find out, and don't plan to.

What surprised me most through all this is how the OEM pipeline has shifted. When I bought this radio in late 2022 I could find OEM replacement packs for around $50 to 70 from a couple of US distributors. Now the same OEM part runs closer to $100 to 120 when you can find it in stock at all, and most of the listings I'd actually trust are either rebadged inventory from industrial radio resellers or estate-sale style decom batches from fleet changeouts.

Right now I'm sitting on one tolerable aftermarket and one that's going back. Planning to bite the bullet on a $95 OEM through a fleet decom listing I found on a smaller B2B parts site, mostly because two failed aftermarket purchases in a row has me thinking the cost premium is worth not doing this dance again in 18 months. If I had to redo this I'd skip Amazon entirely and start with the industrial resellers. The markup is real, but apparently so is the consistency.