The fastest way to abandon a new tool is to try to configure all of it on the first evening. You connect nine platforms, upload forty images, schedule a month of posts, get one rejection you do not understand, and do not open it again for a fortnight.

The alternative is seven short sessions, each with a single outcome and a definition of done. None of them takes longer than the time you would spend scrolling. By the end of the week you have a system that runs itself for a few days at a time, and — more importantly — you know which part of it breaks first, because you have already seen it break once in a controlled way.

Each day below lists the task, why it matters, and what "done" looks like. If a day blocks, the guide that unblocks it is named rather than implied.

Before day one: which kind of user you are

This guide has two audiences and they start in different places.

You are using a hosted deployment where somebody else has already put the platform keys in place. Skip to day one; your first task is connecting accounts, not configuring anything.

You are the administrator of your own deployment. Spend twenty minutes first on the API keys guide: create the applications on the portals you need, put the client ids and secrets in the environment, restart, and confirm that /api/platforms/health reports your platforms as configured. If you skip this, every day afterwards hits the same wall — a greyed-out Connect button with a Keys missing badge — and you will spend the week rediscovering it.

Either way, the measure of readiness is the same: open Connected Accounts and see that the platforms you intend to use offer a real Connect button rather than a missing-keys message.

Day one: connect two platforms, not nine

Task. Connect exactly two accounts: one that uses a redirect flow (X, LinkedIn, Facebook, Instagram, Threads, YouTube, TikTok, Tumblr, Pinterest, Dribbble, Vimeo, TikTok or Google Business Profile) and one that does not (Bluesky, Telegram or Mastodon).

Why two, and why one of each kind. Connecting nine OAuth platforms teaches you nothing that the first one did not, but it takes nine times as long and produces nine chances to hit an approval delay you cannot control. Connecting one OAuth account proves the redirect, callback and token exchange all work on your deployment. Connecting one credential-based account proves the non-OAuth path works too. Together they exercise every mechanism in the product, and the second one takes about a minute.

What to watch while you do it. On the OAuth platform: you leave the site, you approve on the platform's own domain, and you come back to a success toast. If you come back to an error instead, read the message — it names either the callback URL mismatch or a permission problem, and those have different fixes.

On Bluesky: generate an app password in your own settings first, then paste it with your handle. On Telegram: create the bot with BotFather first, add it to the target chat, and send one message in that chat so it has somewhere to post.

Done looks like: two cards on Connected Accounts reading Connected, the header counter showing two of fifteen channels, and Re-check config returning without error.

If you only manage one today, that is still a successful day one. The second one will take a minute tomorrow.

Day two: prepare media, not content

Task. Choose the handful of images you will actually publish this week and get them into the right shape before you write anything. Upload them to the media library.

Why media comes before writing. Because media is where posts fail, and they fail at the moment of publishing rather than at the moment of composing. A JPG that is 9 MB passes the upload and fails on X. A WebP passes the upload and fails on Dribbble. A 1200x800 image passes everything except Dribbble, which demands exactly 400x300 or 800x600. Discovering this while writing is how an evening disappears.

The three rules that cover almost everything. Export JPG or PNG. Keep each file under about 2 MB and definitely under 10 MB. Make a separate, smaller export under 900 KB if Bluesky is in your platform list. If Dribbble is in your list, add the exact-dimension export to that set.

Upload them through the media library so that you can see them, confirm the preview, and know that the file you are about to attach is the file you think it is.

Done looks like: five to ten images in the media library, all of them JPG or PNG, none over 10 MB, and none of them the wrong shape for a platform you intend to use.

The media requirements guide has the full per-platform table if you are unsure about a specific network.

Day three: your first real post

Task. Write one post, attach one image, select one platform, and save it as a draft. Then open it in the calendar and schedule it for a time in the future.

Why a draft first. Because the draft path has no timer attached to it. Nothing can go out. You can see how the composer behaves, how the platform picker works, how the counter responds when you add a second platform — with zero risk. The first time you press a button that publishes should not also be the first time you see the interface.

Then schedule it. Open the draft from the calendar, set a time an hour or two ahead, and save. Check the queue: the post should appear under the right day with scheduled status. Check the dashboard's next-scheduled card: it should name that post and its time.

The timezone check is the point of this day. Schedule something for a time you will remember — an hour from now, at a round time — and confirm that the queue shows it at the time you picked, in your own clock. If it shows a time five or eight hours away, something is wrong with how the time was stored, and finding that out on a throwaway post rather than on a client's campaign is exactly why this day exists.

Done looks like: a draft that became a scheduled post, the queue showing it on the correct day at the correct local time, and the dashboard's next-scheduled card agreeing with the queue.

If the post went out early or the time looks wrong, stop here and read the scheduling and timezone section of the first-post guide before continuing. Everything later in the week depends on times being right.

Day four: watch it go out, then build the habit

Task. Let the scheduled post publish on its own. Then look at what happened, and set up a two-minute daily check.

Watch. When the time passes, refresh the queue. The post should read published. Open it: if it succeeded everywhere, you have proven the entire pipeline — composer, storage, scheduler, adapter, platform — in one post.

If it failed, this is the best possible time for it. Open the post and read the error. Work through the failure guide's triage list: is it the account, the content or the platform? Fix that one thing and republish from the calendar. A failure on day four, on your own test post, teaches you more than a success does, and it happens while the stakes are zero.

Note the partial case. If the post went out on one network and not another, it will read as published with a warning. Find which platform refused and why. That asymmetry — one platform's rule that the others do not have — is the normal shape of cross-posting, and seeing it once early removes the surprise.

Set the habit. Two minutes, once a day: open the queue, look at what is scheduled for today and tomorrow, and glance at the failed filter. That is the entire daily operating procedure for a scheduling tool. Anything more is procrastination with a chart.

Done looks like: one post published successfully (or one failure understood and fixed), and a daily two-minute check you have actually performed once.

Day five: batch a week of content

Task. Write and schedule a full week of posts in one sitting — three to five posts, depending on your cadence — using what you learned on days three and four.

Why batching. Not because it is a productivity slogan, but because you now know the constraints: the character limit of the tightest selected platform, the media rules, the timezone behaviour, and which platforms accept what. Those constraints are much cheaper to apply while you are already in the editor than to discover one at a time across five separate evenings.

How to structure the sitting. Write the global text for each post first, so the week's ideas are on the page. Then, for each post, decide the platform set and add per-platform overrides only where a platform genuinely needs different words. Attach media. Schedule each one for a specific day and time. Do not press publish on any of them.

Watch the counter. The composer caps the global text at the tightest selected platform's limit and labels which platform is responsible. If you are writing for LinkedIn and X together, 280 is the ceiling for the shared version — put the longer LinkedIn paragraph in its override rather than dropping X from the selection.

Watch the cost chip. If X is selected, the amber chip shows what this post will cost — 0.015 dollars without a link, 0.200 with one. A week of link posts to X is a number worth seeing before you schedule it rather than after.

Done looks like: five posts in the queue, spread across the week, each with media attached, each with a time you can explain, and the failed filter still empty.

If the queue ends up with three drafts and no scheduled posts, the batch did not happen — drafts are ideas, not a schedule. Schedule at least two of them before you close the laptop.

Day six: audit the week and read the dashboard honestly

Task. Spend twenty minutes reviewing what you have built: the calendar for the week ahead, the queue for the week behind, and the analytics page for the shape of your publishing.

Calendar ahead. Every day you intend to publish should have something on it. Empty days are either deliberate (a rest day) or a gap — decide which, in writing if it helps, because an unexamined gap becomes a habit.

Queue behind. Filter to published and check the count matches what you scheduled. Filter to failed and deal with anything there — a failed post does not retry itself and will sit there indefinitely.

Analytics, with the right expectations. Posts published and posts per week are real, and they are the numbers to read today. Engagement and follower figures on this screen are placeholders until the metrics sync is connected; do not plan against them and do not put them in a report. The analytics guide spells out what is measured and what is pending.

The useful question for day six is not "how did we do" but "is the rhythm real". Three posts a week for two weeks running is a rhythm. Twelve posts in one day and silence afterwards is a burst.

Done looks like: next week's calendar has something on the days it should, the failed filter is empty, and you can state your cadence in one sentence.

Day seven: decide what you are paying for

Task. Look at your actual usage and decide whether the plan you are on matches how you intend to work.

Where to look. The billing page at /dashboard/billing shows your current plan, posts used against the allowance, connected accounts against the limit, and the renewal date when one exists. The composer shows the same posts-remaining figure while you write.

How to decide. One brand, three accounts, a handful of posts a week: the entry plan's limits are unlikely to bind, and the features you would use — calendar, media library, drafts, scheduling — are in every tier. Multiple people touching the content, or a requirement that something be approved before it publishes: you are in the tier that includes approvals and seats. Client-facing reporting under someone else's name, or exports into another system: that is the top tier.

What happens when you press Pay. The checkout shows you the order in rupees, with the exchange rate that produced it, and then tells you plainly that the payment gateway is not connected yet and that no charge was made. That is the current state of billing, and the pricing guide covers it in full. Nothing is charged, nothing is downgraded, and your plan stays where it is.

Done looks like: you know your plan, you know your usage against it, and you know which tier you would move to and why.

When something blocks you

Four guides cover essentially everything that stops week one, and knowing which to open saves the wandering:

The connect guide when a badge will not turn green, when a redirect bounces you back with an error, or when you need to know what each status means.

The API keys guide when the button says Keys missing — that is an environment problem, and the guide has the variable names and portals.

The first-post guide when scheduling behaves oddly, when a time looks wrong, or when you want to understand what the three buttons actually do.

The failed-publish guide when something refuses a post, which has a triage list ordered by how often each cause occurs.

The media guide when an image is rejected, which is the most common single cause of a partial failure.

Read the one that matches the error in front of you rather than the one that matches the feature you hoped to use. The message text is specific on purpose.

How long each session actually takes

Planning around a week is easier when the sessions are sized honestly rather than optimistically.

Day one, connecting accounts: ten to twenty minutes if you already have the keys configured, considerably longer if you are the administrator creating them. The first OAuth connection takes the longest because you are reading a portal for the first time; the second takes a third of the time.

Day two, media: thirty minutes or more if you are preparing a week's worth of exports, five minutes if you are pulling from an existing library. This is the session most often skipped, and the one whose skipping is most expensive later.

Day three, the first post: fifteen minutes including the timezone check. The draft itself takes five; the careful part is confirming the time is what you think it is.

Day four, watching it publish: two minutes of attention at the scheduled time, plus however long the failure diagnosis takes if there is one. Budget ten minutes and treat the remainder as a bonus.

Day five, the batch: forty-five to sixty minutes for five posts once the media is ready. This is the session that sets the tone for everything after it, and it is the one worth putting in your own calendar as an appointment.

Day six, the audit: twenty minutes.

Day seven, billing: ten minutes of reading and deciding.

Add it up and week one costs about three hours, spread thin. The second week is cheaper, because the media habit and the batch habit are already in place.

Before day one: decide four things on paper

None of these are technical, and all of them cause a stall later if they are left undecided.

Which platforms, and how many. Two is right for week one. Picking four or five because they are all supported is how people end up with a disconnected Instagram and no posts anywhere. Choose the one or two where your audience actually is; the rest can be added in week three.

What your cadence is. Three posts a week? Five? One a day? Write the number down. Every later question — how many posts to batch on day five, whether the calendar has gaps, whether the plan's allowance is adequate — is answered relative to this number, and it is much harder to answer without it.

Where the images come from. Photography you shoot, a designer's exports, stock, or screenshots. Whatever the answer, it needs to be reachable on day two, because a media library you cannot fill turns day five into an exercise in frustration.

Who writes and who approves, if it is not one person. In this build there are no seats and no roles, so if more than one person is involved you are sharing a login or taking turns. Decide now, because the offboarding and audit questions in the security guide depend on you having made a deliberate choice rather than an accidental one.

Ten minutes with a notebook prevents the most common week-one stall, which is arriving at the composer and not knowing what to write — a writing problem wearing a tooling costume.

What to do when you only have three days

The full seven-day version is the right one. The compressed version below keeps the two sessions that matter and folds the rest around them.

Day one: connect two platforms, write one post, schedule it. Combine days one and three. The timezone check is not optional — it is the single test that proves the whole system is storing times correctly, and skipping it is what leads to discovering a five-hour offset on day nine instead.

Day two: batch the week. Compressed days two and five together. Prepare media and write in one sitting. Expect it to take longer than the unbundled version, because you are doing the media thinking and the writing thinking at the same time.

Day three: audit and decide. Compressed days four, six and seven: check what published, check the failed filter, read the billing page, note the gaps.

Three sessions, about two hours, and you have the same proof points: a verified time, a published post, an empty failed filter, and a week scheduled. What you lose is the chance to see a failure happen under controlled conditions on day four — which means you should expect to meet that failure during the batch instead, and treat it as the day-four lesson arriving late rather than as a new problem.

If you have only one session, do this: connect one platform, publish one real post immediately, and look at the result. That single end-to-end pass teaches more than any amount of setup done in advance of publishing something.

Three weeks that go wrong, and what they teach

The keys are not configured. You reach day one and every platform you want shows a Keys missing badge. Nothing you do inside the product will fix it, because the credentials live in the server's environment. This is the moment to hand the API keys guide to whoever maintains the deployment, or to become that person for twenty minutes. The temptation is to keep clicking Connect and hope; the button is disabled for a reason and the badge names the variables that are absent.

The timezone was wrong after all. You scheduled something for 2 pm and the queue shows 9 pm. Nothing is broken in the usual sense — the time you picked was interpreted in a different zone than the one you meant, which is exactly what day three exists to catch. Fix the time on that post, check every other scheduled post for the same offset, and then re-read the queue after scheduling anything else for a week. One offset discovered early is worth far more than a month of quiet drift.

Every platform failed on day four. The post is refused everywhere with token or permission messages. This is a connection problem rather than a content problem, and it means day four did its job: you found out that your connections expire or were revoked while the stakes were still a test post. Reconnect one platform, confirm it alone publishes, then the rest. If instead the message is about media on every platform, the file is the problem — check it against the media guide before touching anything else.

The common thread: none of these three is a reason to abandon the week, and all three are cheaper to meet now than during a client campaign in month two.

Signals that week one worked

You do not need a dashboard to judge whether the week went well. Six observations are enough, and five of them take under a minute.

Something published without you pressing a button. That is the entire product thesis. If a scheduled post went out on its own, the scheduler, the connections and the timing all work.

The failed filter is empty — or was emptied after a failure you understood. An empty filter is ideal; a failure you diagnosed and fixed is nearly as good, because it proves the recovery path.

The calendar for next week has entries on the days you intend to publish. Not drafts — scheduled posts with times.

You can state your cadence in one sentence, and the queue agrees with it. Three a week is three a week, not three when convenient.

The batch took less time than you expected, or you know why it took longer. Either outcome is information; the only bad result is not knowing where the time went.

Someone else could find a post in the queue without asking you where it is. A crude test of whether the system is legible or merely familiar to you. If only you can navigate it, the habits are yours rather than the team's.

If five of those six are true, the week worked and the second week is about consistency rather than setup.

The version for two people or more

Week one works slightly differently when it is not just you, and the differences are worth naming before you start rather than after a confusing Tuesday.

Decide the login shape first. This build has no seats and no roles, so the honest choice today is between one shared account and taking turns on individual accounts. A shared account means everyone sees everything and anyone can publish; individual accounts mean the person who scheduled a post may not be the person who can edit it. Neither is wrong, but the shared-account choice should be deliberate, because it is the one that needs an offboarding procedure later.

Split the days by mindset rather than by convenience. The person who writes should own days three and five — the first post and the batch. The person who worries about things should own days one, four and six — connections, the failure check, the audit. Day two, media, belongs to whoever produces the images. Splitting this way means the writer is never blocked on a portal, and the operator is never blocked on a caption.

Write the cadence down somewhere both of you can see. Three posts a week, Monday Wednesday Friday, is a sentence. Without it, each person assumes the other has scheduled something, and the calendar's gaps get discovered on Thursday.

Agree what happens when a post fails. In practice this means agreeing who looks at the failed filter and how quickly. A failure found within a day is a fix; a failure found in a month is a missed campaign. The queue's failed filter is the only place this is visible, so assign it explicitly.

Use the approvals screen if the risk justifies it. For a shared login, approvals are the one mechanism in the product that puts a deliberate human action between a draft and the public internet. It is heavier than a verbal agreement, and it is the correct choice when the cost of a wrong post is high — client work, regulated claims, anything with a legal dimension.

What does not change for teams: every day's definition of done, the timezone check, and the two-minute daily queue review. The week's shape is the same; only the ownership moves.

The checklist, flattened

If you would rather have one list than seven days:

• Two accounts connected — one OAuth, one credential-based.
• Re-check config pressed and clean.
• Five to ten images in the media library, correct format, correct size.
• One draft written, then scheduled, with the timezone verified.
• One post published — or one failure understood and fixed.
• A full week scheduled in one sitting, with per-platform overrides where needed.
• The failed filter empty.
• Next week's calendar checked for gaps.
• The billing page opened and your usage understood.
• The daily two-minute queue check performed at least once.

Ten items. If you get through them, the tool is doing its job and you have the habits to keep it that way.

What is worth writing down as you go

Week one generates a small pile of facts that you will need again and will not remember. Four lines in a note file are enough, and each one saves a future search.

Which platforms you connected and when. A connection made on day one that starts failing in month two is much easier to diagnose if you know whether it has ever worked, and how long ago.

The callback URL and portal you used for each platform — only if you configured keys yourself. The URL pattern is fixed but the portal tabs move, and your note of where you found the field last time is worth more than the guide.

Your cadence, in one sentence. Three posts a week, Monday Wednesday Friday. This is the number every later decision is measured against.

Where the media comes from. The folder, the designer, the stock account — whatever it is, name it, so that day five of next month does not begin with twenty minutes of hunting.

Anything that failed and how you fixed it. One line per incident. This is the beginning of the failure log the triage guide recommends, and starting it in week one costs nothing because there is barely anything to write yet.

None of this is documentation in the corporate sense; it is a note to the person you will be in six weeks, who will not remember which of the four platforms you connected first or why the Bluesky image needed its own export.

After week one

The second week is where the system either starts saving time or quietly stops being used. The difference is almost never motivation; it is whether the batch happens on a schedule.

Pick a day for the batch, put it in your own calendar as an appointment, and protect it for the length of time day five actually took — usually less than an hour once the media is prepared and the constraints are known. Everything else in this product is designed to run in the background between those sessions: the scheduler publishes, the queue reports, and the two-minute daily check catches the one thing that needs a human.

Give it a month before you judge whether it worked. A month of steady rhythm tells you something about the system; a week of enthusiasm followed by silence tells you only that week one was energetic.