gms

They've been around since before their current owners were born and espousing the same philosophies.

Does it generate native apps, or just Electron?

That's how the world works. No country produces everything.

No. It's a similar situation with certain AI features from Google.

I also found this to be a fun read! Was intending to skim but ended up reading the whole thing. The level of care shines through - nice work.

No, there is a difference. Burglary involves coercion. The choice to shop at small/big bakeries is yours alone; no one is forcing you to pick one.

This is a common rite of passage for early-stage startups :)

The answer may sound glib but I don't mean it as such: don't have an unlimited plan and migrate existing customers off it.

At the end of the day it's just a VC's view. This doesn't count for much.

You two can easily tell him no thanks and move on.

Some arguments here from a bygone era (none are convincing to me): https://hbr.org/2016/02/the-very-first-mistake-most-startup-....

We have the same model as you at the company I co-founded. The only valid worry that comes to my mind is a 50-50 split with no person designated as the boss. But you already have that part sorted.

At least amongst Bay Area startups at your stage, a 50/50 split is common. It has its advocates (YC amongst them) and detractors.

Given how common this is, it's peculiar that this VC is bringing this up so early in the lifetime of the company. CEOs often get different refresher packages as the company grows and assembles a board, but you're not at that stage yet.

If your co-founder is happy with the current arrangement then he can just tell the VC no thanks and everyone can move on. It's your company, not your VC's.

More generally, the most troublesome part of all this is that, at your early stage, every minute spent talking about this is a minute not spent on your product and customers.

Sorry, my fault for being unclear.

Meaning, sometimes people set up one-way syncs only. Our syncs don't have to be two-way.

That's no problem for us. We'll just resume where we left off when it comes back on.

(Polytomic co-founder)

Haha! I’ve been in this market for over ten years now. The term ‘CDP’ is notoriously ill-defined.

More generally, we move data in all directions, rETL is just one part amongst many others.

Each integration is supported as both a source and a destination. So you can have two one-way syncs set up between systems A and B, thus moving data in two directions.

(Polytomic co-founder here)

QuickBooks Online. All the applications we support are cloud versions.

(Polytomic co-founder here)

Each sync in Polytomic is one-way so we're not forced to deal with collisions all the time.

But you can, on a per-field basis within a sync config, declare that field not to be synced if the destination system already has a value in the corresponding field.

This setting is a proxy for deciding where your source of truth is for each field if you are indeed setting up two-way syncs.

Most customers are pulling data into their data warehouse, then syncing from queries that generate other values back into other systems. This issue doesn't come up there. But customers of ours doing two-way syncs between, say, HubSpot and Airtable or such do need to decide where the source of truth is for each field.

Hopefully the links below are helpful!

Our clients come in multiple languages. You can see the list here: https://apidocs.polytomic.com/guides/native-clients.

You can see here for sample code: https://apidocs.polytomic.com/guides/code-examples/overview.

The full API reference is here: https://apidocs.polytomic.com/api-reference.

Wow thank you Noa! Hope you are well!

What are you looking for exactly? Happy to answer questions or point you to the right place.

(Polytomic co-founder)

Thank you for the kind words Ani!

(Polytomic co-founder)

Thank you, whoever you are! :D Hopefully we can continue serving you.

We're talking about system-to-system pulls and pushes.

For example, maybe your product needs to process data from your customers' sales and customer support systems. In that case you can have automatic updates show up in Postgres from your customers' Salesforce and Zendesk instances. Does that sense?

Alternatively, many products want to the ability to push data to their customers' systems. For example, suppose you're a billing software vendor showing data in your own portal that customers log in to. Your customers may also want you to automatically push this data to their accounting systems or data warehouses so that they can do their own analysis.

Does that make sense?

(Polytomic co-founder here)

We automatically do the right thing depending on the situation. The type engine is highly-precise when we generate our own schema. For example, JSON objects and arrays get converted to native struct and array types in data warehouses (e.g. Databricks, BigQuery) rather than strings.

But we're forgiving in other situations where we don't control schemas. For example, we'll automatically convert a source string type to a date when mapping to a Salesforce or Zendesk (or other cloud app) date field.

(Polytomic co-founder)

Thanks for the kind words! Pleasure serving you.

Thank you! We're happy to serve.

Hello! Polytomic co-founder here.

1. All integrations are built on request (see instruction at top of this page to submit one: https://www.polytomic.com/integrations). We're able to turn them around very quickly (our record is two hours from request submission time).

2. Yes, though you can bring your own compute too. We have a self-hosted distribution that you can deploy to your own VPC using Docker and our Terraform module (see details here https://docs.polytomic.com/docs/on-premise-setup). Customers that are public/large enterprises often go for this.

If you want to chat over email shoot me a message at ghalib@polytomic.com.

No. Unfortunately wielding them is always an act of either ignorance or malice.

iMessage and FaceTime Audio are also free.

I don’t as I don’t know the numbers, but note also the US is a rich country.

Nobody uses iMessage outside the US, by choice, even in iPhone-dominated markets. So clearly it's possible to avoid it. US iPhone users have the same choice.