u/FollowingSuitable941

29M salaried, unmarried right now but marriage probably in the next 1-2 years, Parents are partially dependent on me and I'll most likely take a home loan in the next few years.

After doing the usual calculator hopping and unwanted advisor calls, I've more or less decided on ₹4 crore term cover till age 65.

I’m currently leaning towards Aditya Birla Sun Life Insurance, ABSLI, mainly because the premium payment choices are quite flexible and easy to understand. I’m not being forced into only one weird structure.

The two ABSLI options I’m properly considering:

Option	Premium payment	Approx premium
Regular pay	Every year till 65	₹37000/year
Limited pay	Finish in 10 years	₹96000/year

The base cover and policy duration are the same in the quotation. The only major difference is how quickly I finish paying.

Spreadsheet answer seems obvious: take regular pay, invest the difference and let inflation make the fixed premium feel smaller every year.

But real-life answer is where I’m confused.

My income is good right now, but I work in a sector where layoffs are not exactly rare. Ten years from now I’ll probably have a home loan, kids and much higher monthly expenses.

There is some appeal in finishing the ABSLI premiums while my liabilities are still relatively low and then entering my 40s with the term plan fully paid.

On the other hand, paying almost double right now just for “mental peace” might be financially stupid. That extra amount can remain invested and liquid instead of going to the insurer early.

My actual concerns:

• What happens if I miss a regular premium 15–20 years later?
• Is limited pay genuinely useful or mostly sold because insurers receive money earlier?
• Does inflation make regular pay the obvious winner?
• Should unstable future employment make me prefer limited pay?
• Do riders continue for the complete policy term under both options?
• Would you choose mathematical optimisation or remove the future obligation?

ABSLI is currently my preferred insurer because I like having both choices instead of changing the entire plan just to change the premium-payment period.

Just not able to decide wheter I should optimise for returns or for the relief of knowing this expense is permanently done.

Please no agents in DM . Reddit Maths and practical experiences are enough 😭.

first live version is already built using nubra’s python sdk.

honestly the sdk is clean. auth, instruments, orders, positions and market data took much less code than building the whole http layer myself.

now deciding whether to keep it directly in production or put a thin internal client over nubra’s v3 rest api.

things pushing me toward raw rest:

- exact timeout control

- logging the complete request/response

- reproducing failures with curl

- fewer surprises during sdk upgrades

- easier use from non-python services later

but this may just be engineering trust issues. the sdk already removes a lot of boring plumbing and i can pin the version.

other option is wrapping the official sdk behind my own `Broker` interface, so strategy code never imports nubra directly.

what are people actually doing in live systems?

official sdk directly? wrapped sdk? generated rest client? or sdk for market data and raw rest for execution?

main concern isn’t speed. it’s being able to explain exactly what happened after one ugly order failure six months from now.

Feels Like every second AI startup is some version of:

AI receptionist
AI SDR
AI support caller
AI appointment setter
AI collections agent
AI booking bot

Not syaing these are bad businnesses. Some will work.

But the wrapper layer already feels crowded

The thing that still feels messy is the boring voice infra underneath.

Real-time STT.
Interruptions.
Caller corrections.
Field capture.
Redaction.
Timestamps.
Call evidence.
Speaker turns.
Phone audio.
Latency logs.
Debugging why the agent failed.
Knowing whether STT, LLM, TTS or telephony caused the bad call.

A lot of “AI voice agent” products are basically only as good as their weakest speech layer.

If the agent hears the wrong date, wrong phone number, wrong refund amount, or misses “don’t”, the wrapper doesn’t matter. The customer just sees a broken product.

This is why Smallest AI Pulse is interesting to me. It is not trying to be another full AI receptionist wrapper It is closer to the real-time STT / ASR layer where many voice agents quietly break.

Boring infra usually looks less sexy than the demo app, but it can be the part everyone ends up needing.

For people building in voice AI: is there still room in the infra layer, or is the whole market already too crowded?

Coming to USYD alone this semester and every decent PBSA ensuite I'm seeing is around $650- 700 pw.

That is an insane amount of money. but its furnished, bills are included, close enough to campus and I won't have to find random housemates from another country.

A sharehouse is oviously cheaper. But looking one before arriving feels sus, and doing an Airbnb for a month while inspecting rooms sounds stressful af.

UniAcco helped me compare the actual contract cost instead of only the weekly price. One "cheaper" room had a longer contract and barely included anything, while another cost more pw but covered bills and had a shorter term.

Still feels like I'm paying a massive panic tax just because I'm arriving alone.

Has anyone done PBSA for the first semester, met people and then moved into sharehouse?

Worth it as a soft landing or will I hate myself when the rent leaves my account every week?

I keep seeing Playwright MCP and Playwright tests discussed like they are the same thing.

They're not. At least not in the way I'm using them.

Playwright MCP is great when the agent does not **know the page yet**.

Open this app. Inspect the current state. Find the login button. Work out why the modal is not appearing. Try a different path. Read the error. Take a screenshot.

That interactive loops is genuinely useful.

But I'm less convinced that the same loop should become the permanent verification method for a flow we already understood.

For a known check like:

Log in, change the billing address, save it, refresh and verify the new address persisted.

…I don’t really need the coding agent to rediscover the page, inspect everything and then decide whether it probably worked.

I need a boring contract:

• run the flow
• verify the explicit outcome
• return pass or fail
• preserve evidence
• exit non-zero in CI if it failed

That is the distinction I’m currently making:

MCP for exploration.
A proper test or bounded CLI check for verification.

I’ve been looking at Kane CLI from TestMu AI for that second layer.

You give it the objective rather than manually scripting every selector. It runs the browser flow and returns structured output, evidence and an actual result that another agent or CI job can consume.

The useful part is not “AI clicks browser”.

MCP already does that well.

The useful part is turning a fuzzy coding-agent task into a bounded verification step instead of another long browser conversation inside the same context.

And once a flow becomes important enough, Kane can export the completed run to Playwright-currently Python Playwright-so it does not need to remain a natural-language check forever.

I would still rather own a normal Playwright test for:

• payments
• permissions
• destructive actions
• core authentication
• anything expected to run for years

But for PR validation, bug reproduction and temporary smoke coverage, writing and maintaining a full test immediately can also be overkill.

So my current mental model is:

Explore with MCP.
Verify with a bounded check.
Promote stable, important flows into Playwright tests.

Where do you draw that line?

At what point does an exploratory browser flow deserve to become a permanent regression test?