Building the next generation of trust & estate planning software
Dynasty is building a modern trust platform for startup founders and families, with a focus on QSBS trust stacking so founders can multiply the Section 1202 capital gains exclusion across beneficiaries. We make it possible to set up, fund, and maintain QSBS eligible trusts with ongoing compliance through a vertically integrated model that includes trust administration
We are based in San Francisco and work together in person.
Open Roles
- Sales
You will work directly with prospective customers, many of whom are founders, operators, and high net worth families. You will guide them through understanding our solutions, manage pipeline, and close new business. This role is ideal for someone who is consultative, comfortable discussing financial concepts, and excited to help people make important long term decisions.
- Onboarding
You will help new customers successfully set up their trusts through our platform. This includes collecting information, coordinating next steps, answering questions, and ensuring a smooth transition from signup to completed structure. This role is great for someone detail oriented who enjoys guiding people through complex processes with clarity and care.
What We Look For
* Strong communication skills
* Comfort working in person on a small, fast moving team
* High ownership and follow through
* Interest in startups, fintech, or estate planning
To appy: email your resume to kyle <at> getdynasty <dot> com
On some levels its insane that billion dollar companies are pouring resources into something and the name was only relevant for like a couple hours before things moved. Fast paced world.
Singularity of AI project names, projects change their names so fast we have no idea what they are called anymore. Soon, openclaw will change its name faster than humans can respond and only other AI will be able to talk about it.
There was always going to be a first DAO on the blockchain that was hacked and there will always be a first mass network of AI hacking via prompt injection. Just a natural consequence of how things are. If you have thousands of reactive programs stochastically responding to the same stream of public input stream - its going to get exploited somehow
Its crazy to me after all these years that django-like migrations aren't in every language. On the one hand they seem so straightforward and powerful, but there must be some underlying complexities of having it autogenerate migrations.
Its always a surprise when i went to Elixir or Rust and the migration story was more complicated and manual compared to just changing a model, generating a migration and committing.
In the pre-LLM world, I was writing ecto files, and it was super repetitive to define make large database strucutres compared to Django.
Going from Django to Phoenix I prefer manual migrations. Despite being a bit tedious and repetitive, by doing a "double pass" on the schema I often catch bugs, typos, missing indexes, etc. that I would have missed with Django. You waste a bit of time on the simple schemas, but you save a ton of time when you are defining more complex ones. I lost count on how many bugs were introduced because someone was careless with Django migrations, and it is also surprising that some Django devs don't know how to translate the migrations to the SQL equivalent.
At least you can opt-in to automated migrations in Elixir if you use Ash.
There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2].
So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration.
When I've run into this is with data migrations, or if you're adding/assigining permissions to groups.
Did you mean migration signals (pre_migrate and post_migrate)? They are only meant to run before and after the whole migration operation, regardless of how many steps are executed. They don't trigger for each individual migration operation.
The only catch is they will run multiple times, once for each app, but that can also be prevented by passing a sender (e.g. `pre_migrate.connect(pre_migrate_signal_handler, sender=self)` if you are registering them in your AppConfig.ready method).
Does that affect the autogenerated migrations at all? Teh only time I ran into that issue as if I generated a table, created a data migration and then it failed because the table was created same transaction. Never had a problem with autogenerated migrations.
There is no way to autogenerate migrations that work in all cases. There are lots of things out there that can generate migrations that work for most simple cases.
They don't need to work in every case. For the past `~15 years 100% of the autogenerated migrations to generating tables, columns or column names I have made just work. and i have made thousands of migrations at this point.
The only thing to manually migrate are data migrations from one schema to the other.
well in elixir you can have two schemas for the same table, which could represent different views, for example, an admin view and a user view. this is not (necessarily) for security but it reduces the number of columns fetched in the query to only what you need for the purpose.
If it's 5 person company they likely don't have HR or recruiting and the CEO is likely doing the hiring (for VPs/Directors/etc). In that case of course you would communicate with them directly, they are effectively a hiring manager and don't have HR to outsource the hiring to.
If the company has a person/group dedicated to hiring then going around them is counterproductive. IMHO of course!
Agreed. I've worked in startups most of my career, I've messaged CEO's, CEO's have been messaged, never a negative experience and higher quality candidates in my opinion.
the hidden text about financial markets is doubly so. Hate every time i open the news and its "$COMPANY stock falls after $EVENT happens" when often the event probably had no bearing on the stock price of multi-trillion dollar companies at all. It just happened at the same time and the news networks want to construct a narrative.
It's maddening that $100k purchases get totally nerfed by bad software. Absolutely crazy to me that I can go out find a super nice car I want and have to walk away because of bad software or no carplay support.
Building the next generation of trust & estate planning software
Dynasty is building a modern trust platform for startup founders and families, with a focus on QSBS trust stacking so founders can multiply the Section 1202 capital gains exclusion across beneficiaries. We make it possible to set up, fund, and maintain QSBS eligible trusts with ongoing compliance through a vertically integrated model that includes trust administration
We are based in San Francisco and work together in person.
Open Roles
- Sales
You will work directly with prospective customers, many of whom are founders, operators, and high net worth families. You will guide them through understanding our solutions, manage pipeline, and close new business. This role is ideal for someone who is consultative, comfortable discussing financial concepts, and excited to help people make important long term decisions.
- Onboarding
You will help new customers successfully set up their trusts through our platform. This includes collecting information, coordinating next steps, answering questions, and ensuring a smooth transition from signup to completed structure. This role is great for someone detail oriented who enjoys guiding people through complex processes with clarity and care.
What We Look For
To appy: email your resume to kyle <at> getdynasty <dot> comreply