DEV Community: Anne Marcus

How to Build an Email List Before Your Book Launches

Anne Marcus — Sat, 14 Nov 2026 16:57:38 +0000

Ask experienced authors what they wish they had done sooner, and most of them give the same answer: start the email list earlier. Social media accounts can change their rules overnight. A store can bury a book in search results. An email list belongs to the author, and it reaches readers directly. Building one before launch day is one of the highest-value things a first-time author can do.

The first step is to pick a simple email service and set it up early. There are several free options for small lists, and any of them will do to start. The important thing is to choose one and stop shopping around. The list needs a signup form, a welcome email, and a plan for what subscribers will receive. That is the whole setup. Anything more can wait until the list grows.

The second step is to give readers a reason to sign up. Nobody joins a list for nothing. The best reason is something useful and free, often called a reader magnet. For fiction authors, a free short story, a deleted scene, or the first three chapters of the book works well. For nonfiction authors, a checklist, a worksheet, or a short guide related to the book topic works well. The free item should be good. It is the first sample of the author's work, and readers will judge the book by it. A rushed, sloppy freebie does more harm than no freebie at all.

The third step is to put the signup form where readers can find it. The author's website is the main home for it, on the homepage and on every book page. Social media profiles should link to it too. The back pages of the book itself, in the ebook and the print edition, should include a short invitation with the signup link. Many readers finish a book and want more from the author right then. A line at the end of the book catches them at the perfect moment. Authors who publish short stories or articles elsewhere can add the signup link to their author bio there as well.

The fourth step is to write to the list before the book launches. This is where most new authors freeze. They worry they have nothing to say until the book is out. That is not true. Readers who sign up early want the journey. A short email about the cover design, a note about a research trip, a question about which chapter title sounds best, or a simple update on the writing progress all count. These emails build a relationship. By launch day, the list is not a group of strangers. It is a group of people who have been following along and want to see how the story ends.

Frequency matters more than length. One email every two to four weeks is enough before launch. Short emails beat long ones. A few paragraphs, one clear idea, and a friendly tone will do. Consistency matters most of all. An author who emails regularly for six months builds trust. An author who emails three times in one week and then disappears for four months loses it.

The fifth step is to plan the launch emails in advance. A good launch sequence is simple: one email a week before launch to build excitement, one on launch day with the purchase links, and one a few days later for the people who missed the first one. Each email should have one clear purpose. The launch-day email should make buying easy, with the book cover, a short description, and the purchase links right at the top. Readers should not have to scroll to find out how to buy.

There are a few mistakes that new authors make again and again. The first is buying a list of email addresses. Never do this. Bought lists are full of people who never asked to hear from the author, and email services will penalize the account for sending to them. The second mistake is emailing too rarely. A list that hears nothing for a year is a dead list. When the author finally writes, most readers will not remember signing up. The third mistake is only emailing when there is something to sell. A list that only gets sales messages feels used. Readers stay when the emails are interesting, useful, or fun, not only when there is a new book to buy.

Growing the list takes time, and the numbers will be small at first. Ten subscribers feels tiny. Fifty feels slow. But a list of fifty real readers who chose to sign up is worth more than five thousand followers who scroll past every post. Email gets opened. Social posts get missed. Studies of reader behavior keep showing the same thing: email remains one of the strongest ways to reach readers who actually buy books.

A few practical habits help the list grow steadily. Mention the list in every interview, podcast, and guest post. Offer the free item at every book event and signing. Ask happy readers to forward the welcome email to a friend who might like the book. Add a signup link to the email signature. None of these steps is hard. Together, they add up.

Authors should also keep the list clean. Remove addresses that bounce. Let people unsubscribe easily, and do not take it personally when they do. A smaller list of engaged readers beats a big list of people who never open anything. Email services reward good open rates, and a clean list keeps the author's messages out of the spam folder.

For authors who want help with the launch as a whole, including the mailing list and the book itself, working with a publishing team can take a lot of the pressure off. A team like NextGen Book Publishers helps authors get their books ready and guides them through the steps that surround a launch, so the author can focus on writing and connecting with readers.

An email list is not a technical project. It is a group of readers who raised their hands and said they want to hear more. Build it early, treat it well, write to it regularly, and it will be there on launch day, ready to buy the book and tell their friends.

What Editors Actually Fix (and What They Leave Alone)

Anne Marcus — Sat, 14 Nov 2026 16:53:34 +0000

Many first-time authors imagine an editor as a red pen with a person attached. They picture every sentence being rewritten, every paragraph rearranged, and their voice smoothed away until the book sounds like someone else wrote it. That picture is wrong, and it keeps good writers from getting the help their books need. A good editor does not take over a book. A good editor makes the book the author meant to write.

To understand what editors do, it helps to know that editing comes in layers. Each layer fixes a different kind of problem, and each layer leaves a different part of the book alone.

The first layer is developmental editing, sometimes called structural editing. This is the big-picture pass. A developmental editor reads the whole manuscript and asks whether the story or the argument works. In fiction, that means checking the plot, the pacing, the characters, and the ending. Does the middle sag? Does a character change their mind for no reason? Does the opening promise something the ending never delivers? In nonfiction, it means checking the structure of the argument. Does each chapter build on the one before it? Is anything repeated three times? Is a key idea introduced too late?

A developmental editor will leave comments, ask questions, and suggest changes. They might suggest cutting a whole chapter, moving a scene earlier, or giving a side character more room. What they will not do is rewrite the book for the author. The ideas, the voice, and the decisions stay with the writer. The editor points at the weak spots and explains why they are weak. The author decides what to do about it. This layer leaves the sentences alone almost entirely. It is about the shape of the book, not the wording.

The second layer is line editing. This is where the sentences get attention, but it is still not a rewrite. A line editor looks at how the writing flows. Are sentences clunky or repetitive? Is the same word used four times in one paragraph? Does a passage drag when it should move fast? A line editor tightens, smooths, and sharpens. They might suggest a stronger verb, cut a filler phrase, or break one long sentence into two. The goal is clarity and rhythm, not a new voice. A good line editor protects the author's style while removing the friction that slows a reader down.

The third layer is copyediting. This is the detail pass, and it is the one most people picture when they hear the word editor. A copyeditor checks grammar, spelling, punctuation, and consistency. They catch the character whose name changes spelling halfway through, the timeline that has Tuesday following Monday twice, and the comma that changes the meaning of a sentence. They also check facts where facts matter, such as dates, place names, and numbers. Copyeditors follow a style guide, which is a set of rules about things like whether to use Oxford commas and how to format numbers. The author picks the guide, or the editor suggests one, and then the rules stay consistent through the whole book.

The fourth layer is proofreading. This is the final pass, done after the book is formatted and laid out. A proofreader reads the finished pages looking for typos, missing words, and formatting slips that crept in during layout. A proofreader does not fix plot holes or rewrite sentences. Their job is to catch the small errors that survive every earlier pass, because some always do.

Knowing these layers helps an author ask for the right help. A writer who knows the story is solid but worries about grammar needs a copyeditor, not a developmental edit. A writer who feels something is off with the middle of the book but cannot say what needs a developmental editor first. Paying for the wrong layer wastes money and leaves the real problem untouched.

Just as important is knowing what editors leave alone. Editors do not change an author's voice. If a writer uses short, punchy sentences, a good editor will not stretch them into long, flowing ones. Editors do not change the author's opinions or message. A nonfiction author who argues a strong position will not find the editor softening it into something safer. Editors do not invent content. They will point out a gap and ask the author to fill it, but they will not write the missing scene or chapter themselves. And editors do not guarantee sales. A well-edited book has a better chance, but editing is not marketing.

There are a few things authors can do to get the most from an editor. First, finish the manuscript before sending it. An editor cannot fix a book that is still being written. Second, be honest about what the book needs. Tell the editor where the weak spots are. Editors respect writers who know their own work. Third, read the feedback before reacting to it. Some comments sting, especially the ones that are right. Give it a day, then decide. Fourth, ask questions. If a suggestion is unclear, ask the editor to explain it. A good editor welcomes that.

Cost is a fair question, and it varies a lot. Developmental editing costs the most, because it takes the most time and judgment. Line editing sits in the middle. Copyediting and proofreading cost less per word. Some editors charge by the word, some by the hour, and some by the project. Authors should ask for a sample edit before committing. Most professional editors will edit a few pages for free or for a small fee, so the author can see how they work. That sample tells the author more than any website or testimonial.

One practical tip: never skip the copyedit to save money and hope readers will not notice. Readers notice. A book full of typos loses trust fast, and trust is hard to win back. Reviews will mention it. Readers will return it. The money saved on editing often costs far more in lost sales and bad reviews.

For authors who want the whole process handled in one place, working with a publishing team can simplify things. A team like NextGen Book Publishers can guide a manuscript through editing, design, and formatting, so the author is not hiring and managing a separate freelancer for every step.

The fear that an editor will take over a book is understandable, but it is misplaced. Editors are more like skilled readers with a pencil. They find what the author cannot see, because the author is too close to the work. Every published book an author admires went through an editor, often several. The author's voice survived. The book got better. That is what editors actually do.

Choosing the Right Tech Stack for Your First App (Without the Jargon)

Anne Marcus — Sat, 14 Nov 2026 16:48:05 +0000

You have an idea for an app. Maybe it takes bookings, sells a product, or helps customers do something your business already does by phone and email. The idea is clear. Then someone asks what tech stack you are going to use, and the whole project suddenly sounds like a foreign language.

The tech stack is simply the set of tools and technologies used to build the app. The choices matter, but not in the way most first-time founders think. There is no single best stack. There is only the stack that fits your app, your budget, and your plans for the next two years. The good news is that you do not need to understand the jargon to make a good decision. You need to ask the right questions.

Start with what the app has to do. Before anyone talks about technology, the app needs a clear job description. Who will use it? What will they do in it? How often? Does it need to work offline? Does it handle payments? Does it need to send notifications? Does it store sensitive information?

These answers shape everything. An app that shows a menu and takes orders is a different project from an app that tracks deliveries in real time. A simple app with a handful of screens can be built with straightforward tools. A complex app with live data, accounts, and payments needs a stronger foundation.

Write the list of features the app must have on day one, and keep it short. Ten features is a lot. Three to five is normal for a first version. Everything else goes on a list for later. The shorter the list, the simpler the technology can be, and the cheaper and faster the build will be.

Native, cross-platform, or web: the big choice. The first real decision is how the app gets onto a phone. There are three main routes. A native app is built separately for iPhone and Android, using the tools each platform provides. It is the fastest and smoothest option and can use every phone feature, but you are effectively building the app twice, and every update has to be done twice as well.

A cross-platform app is built once and runs on both iPhone and Android. This is the most common choice for a first app, because it cuts cost and build time significantly, and modern cross-platform tools are good enough that most users cannot tell the difference. For a booking app, a shop, or a service app, this is usually the right call.

A web app is a website that behaves like an app. It costs the least, works on every device, and updates happen instantly with no app store approval. The trade-off is that it cannot do everything a real app can do, and some customers expect a proper app they can download. For a first version, or an app people use occasionally, it is often the smartest starting point.

The database and the back end. Every app that stores information needs somewhere to put it. That is the database, and the system that manages it is usually called the back end. Customers never see it, but it decides whether the app is fast, reliable, and safe.

For a first app, the database should be a well-known, widely used one. Popular options are popular for a reason. They are tested, documented, and any competent developer can work with them. Avoid anything unusual or brand new unless there is a strong reason. The newest tool is not the best tool for a business app. The proven one is.

Ask whoever builds the app to explain, in plain English, where the data lives, how it is backed up, and what happens if something goes wrong. If they cannot explain it simply, that is a problem with the plan, not with your understanding.

What to ask a developer before choosing. You do not need to pick the stack yourself. That is the developer's job. What you need is a developer who picks the stack for the right reasons. These questions will tell you whether they are doing that.

Ask why they recommend a particular approach. A good answer connects the choice to your app: this fits because you need it on both phones, or because your budget works best this way. A bad answer is a list of tool names with no connection to your business.

Ask what happens when the app grows. If the app takes off, will the same technology still work? Or will it need rebuilding? A stack that cannot grow is a stack that will cost you twice.

Ask who can maintain it. If only one developer in the world understands the tools chosen, you are tied to that person forever. Choose widely used technology so any good developer can pick up the work later.

Ask about the app stores. Getting an app approved by Apple and Google takes time and has rules. A developer who has done it before will know the common reasons apps get rejected and will build to avoid them.

The mistakes first-time founders make. The most common mistake is choosing technology based on what is fashionable. A founder reads that a big company uses a certain tool, and decides their small booking app should use it too. Big companies choose tools for problems you do not have. Your app needs tools that fit your size, not theirs.

Another mistake is letting the cheapest quote decide. A low price often means an unusual or outdated stack, chosen because the developer already knows it, not because it fits your app. The rebuild later will cost far more than the saving now.

A simple way to decide. If the decision feels overwhelming, here is a short version. For most first apps, a cross-platform build is the best balance of cost, speed, and quality. It runs on both phones, it is built once, and it can be updated easily. If the app is simple and budget is tight, a web app is a strong first step, and it can become a full app later. Native is the right choice when the app needs the best possible performance and full access to the phone, and the budget allows for two builds.

Whatever the choice, get a second opinion from someone who builds apps for a living. A studio like TechCore Studio (https://techcorestudio.com) can look at your idea and tell you plainly which approach fits, what it should cost, and what to watch out for, before you commit to anything.

The tech stack is important, but it is not the project. The project is the app your customers will use, and whether it solves their problem simply and reliably. Get the stack right, and it disappears into the background, which is exactly where it belongs.

The Hidden Costs of Cheap Software (and How to Spot Them)

Anne Marcus — Sat, 14 Nov 2026 16:38:10 +0000

A low quote is hard to resist. A business owner gets three prices for a new website, an app, or a piece of custom software, and one of them is half the price of the others. The choice feels obvious. Six months later, it often feels like a mistake.

Cheap software is rarely cheap. The price on the quote is only the first cost. The real cost shows up later, in fixes, workarounds, lost customers, and eventually a rebuild. The trick is learning to spot those hidden costs before signing, so the decision is based on the true price, not the headline one.

The maintenance bill nobody mentions. Software is not a one-time purchase. It needs care. Operating systems update, browsers change, security holes appear, and customer expectations move on. A well-built system includes maintenance in the plan. A cheap one often does not, and the owner finds out when something breaks.

This applies to off-the-shelf software too. A low monthly price can hide charges for extra users, extra storage, support, or the features that actually make the tool useful. Read the pricing page properly. The plan you need is often two tiers above the one advertised.

The cost of fixing what was rushed. Cheap builds cut corners, and the corners always show. Code that was written in a hurry is hard to change. A small update that should take a day takes a week, because nobody can safely touch the original work without breaking something else.

This is the most expensive hidden cost of all, because it is paid over and over. Every change costs more. Every new feature takes longer. Eventually the business faces a choice: keep paying extra for every small change, or throw the whole thing away and rebuild. Many businesses end up rebuilding, which means they paid twice for the same software.

A good way to judge a quote is to ask how the work will be built and documented. A developer who can explain, in plain language, how the system is structured and how future changes will work is usually building something that lasts. A developer who cannot explain it, or who gets defensive when asked, is a warning sign.

Lost customers are a cost too. Software problems do not stay behind the scenes. A slow website loses visitors. A booking page that fails on phones loses bookings. An app that crashes loses users who never come back and never say why.

These losses are hard to measure, which is why they get ignored. But they are real money. If a website converts two percent of visitors into customers, and a faster, better-built version converts three percent, that one percent difference can be worth thousands over a year. A cheap build that costs half as much but converts half as well is not a saving. It is a loss.

The same applies to staff time. Software that is awkward to use slows down the people who rely on it every day. If a team of five each loses thirty minutes a day fighting a clumsy system, that is twelve and a half hours a week. Over a year, that is more than the price difference between the cheap quote and the good one.

The data and security risks. Cheap software often skips the boring parts, and security is the most boring part of all. Passwords stored badly. No backups. No plan for what happens if the system goes down. These are not problems until they are, and then they are the biggest problem the business has ever faced.

Ask how customer data is stored, how often backups run, and what happens if the system fails. A serious developer will have clear answers. If the answers are vague, or if security is treated as an optional extra, walk away. A data breach or a week of lost records can cost far more than any software project.

Licensing is another trap. Some cheap builds use pirated tools, unlicensed images, or code copied from somewhere it should not have come from. If that is discovered, the business is the one exposed, not the developer who has already been paid and moved on.

How to compare quotes fairly. Comparing software quotes is hard because they rarely describe the same thing. One quote might include design, testing, training, and a year of support. Another might include only the build, with everything else extra. Comparing them on price alone is like comparing a car with an engine to a car without one.

Before choosing, ask every bidder the same questions. What exactly is included? What is not included? What will it cost to change something later? Who owns the code and the data? What happens if you stop working together? How long will support last, and what does it cover?

The answers will tell you more than the prices. The cheapest quote that answers all of these clearly and honestly may genuinely be good value. The cheapest quote that cannot answer them is not a bargain. It is a gamble.

It also helps to ask for references, and to actually call them. A developer with happy customers will be glad to share them. A developer with none will have excuses. Two short phone calls can save months of trouble.

When cheap is fine. Not every project needs a big budget. A simple website, a small tool, or a short trial project can be done cheaply and well, as long as the scope is honest. The danger is not a low price. The danger is a low price for a big job that was never going to fit it.

A good rule is to match the budget to the stakes. If the software is a side project, keep it cheap and simple. If it will run the business, take bookings, hold customer data, or be the main way customers reach you, treat it as the investment it is. Cutting corners on the thing that earns the money rarely pays.

Getting a second opinion is often worth it. A studio like TechCore Studio (https://techcorestudio.com) can look at a quote and say plainly whether it covers what the business actually needs, before any money changes hands. That one conversation can be the difference between a project that works and a project that has to be done twice.

The real question to ask. The question is not how little can this cost. The question is what will this cost over the next two years, including fixes, changes, support, and the customers it might lose along the way. Answer that honestly, and the right quote usually becomes obvious.

Cheap software is tempting because the price is visible and the risks are not. Once the risks are visible, the decision gets much easier. Pay a fair price once, for software that works, lasts, and can grow, and the business spends its time serving customers instead of fixing the tools that were supposed to help.

Landing Pages That Convert: What to Put Above the Fold

Anne Marcus — Sat, 14 Nov 2026 16:29:50 +0000

A landing page has one job: to turn a visitor into an enquiry, a booking, or a sale. And it has only a few seconds to do it. Research on how people browse the web has consistently shown that visitors decide very quickly whether a page is worth their time, and most of that decision happens before they scroll. The part of the page they see first, the area above the fold, is where the decision gets made. Get that part right and people stay. Get it wrong and no amount of good content further down the page will save you, because nobody will ever read it.

Above the fold is an old newspaper term, but the idea still holds online. It means everything a visitor sees when the page first loads, before any scrolling. On a phone, which is where most visitors will see your page, that space is small, so every element in it has to earn its place. The temptation is to fill it with everything: the logo, the navigation, a slideshow, a long list of services, and a newsletter signup. That is exactly the wrong approach. The top of a landing page should do three things and nothing else: say what you offer, say who it is for, and tell the visitor what to do next.

The single most important element above the fold is the headline. It should state the benefit, not the feature. A headline that says, quality landscaping services, tells the visitor almost nothing. A headline that says, a garden you will actually want to spend time in, tells them what life looks like after they hire you. The best headlines speak to the outcome the customer wants, in words the customer would use. They are short, specific, and honest. If your headline could belong to any business in your industry, it is too vague. Make it belong to yours.

Under the headline, a short supporting line does the explaining. One or two sentences that answer the obvious follow-up questions: what exactly do you do, who is it for, and what makes it different. This is not the place for your company history or a list of everything you offer. It is the place for the one or two facts that matter most to the person who just arrived. A cleaning company might say it serves busy families, uses safe products, and offers same-week bookings. That is enough. The details belong further down the page, where interested visitors will find them.

Then comes the call to action, and it needs to be one clear action, not three. Get a free quote, book a call, check availability, whatever the next step is for your business, make it a button that is easy to find and easy to understand. Buttons that say submit or click here do not work well, because they do not tell the visitor what happens next. A button that says get my free quote tells them exactly what they get. Put the button where it can be seen without scrolling, make it stand out from the rest of the page, and resist the urge to add a second button that competes with it. One choice is easy. Three choices are a reason to leave.

Trust signals belong near the top as well, because people are deciding whether to trust you at the same time as they are deciding whether to stay. A short line with a review score, a number of happy customers, or a recognisable credential can make a real difference. A few words like, trusted by over 400 local homeowners, or, rated 4.9 from 120 reviews, gives a new visitor a reason to believe you. This only works if it is true and specific. Vague claims about excellence do nothing. Real numbers and real reviews do a lot.

The image or visual at the top matters too, and this is where many landing pages go wrong. A stock photo of a smiling team in an office tells the visitor nothing about what you actually do. A photo of a real finished project, a real product, or a real result tells them everything. Show the outcome. A roofer should show a finished roof. A bakery should show the cake. A coach should show a client result. The image should help the visitor picture themselves getting the result, not admire a generic picture that could belong to anyone.

Just as important is knowing what to leave out. The top of a landing page is not the place for a long navigation menu, a slideshow, a pop-up, or a form with ten fields. Every extra element is a distraction and a reason to leave. A short form with one or two fields will convert far better than a long one, and the rest of the information can be collected later, once the visitor has already decided to talk to you. Keep the top clean, keep it focused, and let the rest of the page do the convincing for people who want to know more.

Once the top of the page is right, test it. Change one thing at a time, the headline first, then the button, then the image, and watch what happens to enquiries. Small changes in the first screen of a page often produce bigger results than a complete redesign, because that first screen is where most visitors are won or lost. It is worth the time to get it right.

Building a landing page that converts is a skill, and it combines design, writing, and an understanding of how people actually behave online. A design studio like DezignLoop (https://dezignloop.com) builds landing pages for small businesses with exactly this in mind, focusing on the first screen a visitor sees and the single action that matters most. But even if you are working on your own page, the principle is simple: a clear headline, one supporting line, one obvious action, a reason to trust you, and an image that shows the result. Put those above the fold, leave the rest for below, and your page will work a lot harder for your business.

Print, Ebook, or Both? Choosing the Right Format for Your First Book

Anne Marcus — Fri, 13 Nov 2026 16:41:52 +0000

One of the first choices a new author faces after finishing a manuscript is what format the book should take. Print, ebook, or both. It sounds like a simple question, but the answer shapes how the book is made, how it is sold, and who reads it. Anne Marcus has seen many first time authors get stuck on this choice, so it helps to look at each option plainly and match it to the book and the readers you want to reach.

Start with the ebook. An ebook is the easiest format to publish and the fastest to get into a reader hands. There is no printing, no shipping, and no stock to store. A reader can buy it and start reading in a minute. That speed matters for a first book. It also keeps the cost of getting started low, which is a real help when you are testing whether readers want the book at all.

Ebooks also make it easy to fix mistakes. If you spot a typo after launch, you can correct the file and upload a new version. With print, a fix means a new print run or living with the error. For a new author still learning the ropes, that flexibility is worth a lot. Ebooks also travel well. A reader on a phone, a tablet, or an e-reader can carry your book anywhere, and that fits how many people read now, in short sessions on the move.

But ebooks have limits. They are easy to overlook. A reader scrolling through a long list of titles may pass yours by without a second thought. An ebook also gives you nothing physical to hold, show, or sign. If you plan to speak at events, sell at a local market, or hand a copy to someone you meet, an ebook will not do that job. Some readers simply prefer paper, and they will not buy a book they cannot hold.

Print has a different kind of strength. A printed book feels real in a way a file does not. It sits on a shelf. It can be given as a gift. It can be signed. For many readers, that physical presence is part of the pleasure of reading. Print also lends a book a sense of weight. A reader who picks up a well made paperback is more likely to take the author seriously, even before reading the first page.

Print also opens doors that ebooks do not. Local bookshops, libraries, schools, and community events often work with printed books. If your readers are in a local community, or your book suits a live audience, print gives you something to bring with you. A signing table with a stack of books draws people in a way a phone screen does not.

The trade off is cost and logistics. Printing costs money up front, and you need to think about how many copies to order. Order too few and you run out at the wrong moment. Order too many and you have boxes sitting in a spare room. Print on demand has made this much easier. You can order small batches, or let copies be printed one at a time as readers order them. That removes much of the risk, though the cost per copy is higher than a large print run.

So what about doing both. For most first books, both is the best answer, and it is easier than it sounds. Publish the ebook first to get the book out quickly and start learning what readers think. Then add a print version once the text is settled and the cover is ready. The two formats serve different readers, and having both means you do not lose a sale because the format a reader wants is missing.

When you do both, keep the two versions consistent. The cover should look like the same book in both formats, even though the print cover needs a back and a spine. The text should match, so a reader who switches between formats is not confused. And the price should make sense. A print copy will cost more than the ebook, and readers expect that. A large gap can put people off, so keep the difference reasonable.

Think about your readers before you decide. Ask yourself a few plain questions. Where do your readers already read. If they read on their phones, an ebook is the natural first step. If they are the kind of readers who love a bookshop, print matters more. How will they find you. If most of your readers will come from online searches and social media, an ebook is easy to link to. If they will meet you in person, print gives you something to sell on the spot. What is the book for. A short practical guide often works well as an ebook. A gift book, a memoir, or a book you want to share with family often feels better in print.

Genre matters too. Novels, memoirs, and poetry often do well in print because readers keep them and lend them. Practical guides, workbooks, and short reads often do well as ebooks because readers want them quickly and search for them online. But these are patterns, not rules. The best choice is the one that fits your readers, not the one that fits a general trend.

Do not let format delay the book. Some authors spend months weighing print against ebook and never publish at all. That is the worst outcome. A book that is published in one format is far better than a book that stays on a hard drive while the author tries to make the perfect choice. Pick the format that gets the book to readers soonest, publish it, learn from the response, and add the other format when you are ready.

It also helps to think about the order of work. The text is the same in both formats, so finish the editing first. Then format the ebook, which is the quicker job. Then prepare the print files, which take more care with margins, page size, and cover layout. Doing it in that order avoids redoing work. If you are unsure about the print setup, get help with that step rather than guessing. A badly printed book with tight margins or a blurry cover does more harm than waiting a week to get it right.

For first time authors who want practical help getting both versions ready, from formatting to a print ready cover, NextGen Book Publishers supports independent authors through those publishing steps.

In the end, the format is a tool, not the goal. The goal is a reader finishing your book and wanting more. Ebook, print, or both, the choice that serves that reader best is the right one. Start with the format your readers already use, add the other when you can, and let the book do the talking.

What to Look for in a Software Quote (and the Red Flags to Watch For)

Anne Marcus — Fri, 13 Nov 2026 16:37:53 +0000

Getting a quote for software work can feel like comparing prices written in different languages. One quote is a single number. Another is pages long. A third is far cheaper than the rest. For a business owner who is not a developer, it is hard to know what is fair, what is missing, and what will cost extra later.

A good quote is not just a price. It is a plan. It should show what will be built, how long it will take, what is included, and what happens if things change.

The first thing to check is whether the quote is based on a clear brief. A reliable developer will ask questions before pricing anything. What is the software for? Who will use it? What should it do on day one, and what can wait? If a quote arrives after a short call with almost no questions, it is probably a guess. A guess can turn into a much higher final bill once the real work becomes clear.

A clear quote should list the features that are included. Not in vague terms like a full system, but plainly. User accounts and logins. A booking form. Payment handling. An admin area to manage content. Email notifications. Each item should be named, so both sides agree on what done means. If the list is vague, ask for it in writing. That one step prevents most disagreements later.

The quote should also name what is not included. Does it include writing the content, or is that your job? Does it include the app store fees, the hosting costs, or the domain? Does it include training your team? A low quote that leaves out hosting, testing, or support may end up costing more than a higher quote that includes them.

Timing should be there too, broken into stages. Discovery, design, development, testing, and launch, each with a range. A single date with no stages tells you very little. A staged timeline tells you how the work will move, and when you will see progress. It also makes it easier to spot a delay early, while there is still time to fix it.

Payment terms matter as well. Most software work is paid in stages, tied to progress. A deposit at the start, a payment when design is approved, another when the working version is ready to test, and a final payment at launch is a common pattern. Be careful with a quote that asks for most of the money up front. And be careful with one that asks for nothing until the end, since that can mean the developer is stretched thin or juggling too many jobs.

Now for the red flags. The first is a price that is far lower than every other quote. Sometimes a low price is genuine, but often it means the work has been misunderstood, corners will be cut, or extra charges will appear later. If one quote is half the price of the others, ask what is different. What is left out? How many hours are allowed? What happens if the work takes longer? A straight answer is reassuring. A vague one is not.

The second red flag is a quote that promises everything, fast, with no trade-offs. Software work always involves choices. A feature can be quick, cheap, or polished, but rarely all three. A developer who says yes to everything, in half the time, with no questions, is either guessing or planning to disappoint you later. Honest quotes explain the choices and the costs.

The third red flag is no mention of testing. Testing is real work, and it takes time. A quote that jumps from development straight to launch, with no time for testing on different devices and browsers, is a quote that will deliver bugs. Ask how testing is handled, who does it, and what happens to the problems that are found.

The fourth red flag is silence about ownership and access. When the work is done, you should own the code, the design, and the content, and you should be able to move to another developer if you need to. Ask who owns the code, where it is stored, and whether you will have access to it. Ask about passwords, accounts, and hosting. If a developer is unwilling to answer clearly, that is a serious warning sign.

The fifth red flag is no plan for support after launch. Software needs care after it goes live. Phones update, browsers change, and small problems appear. A good quote will say what happens in the first few weeks after launch, and what ongoing support costs. A quote that ends at launch day leaves you on your own at the moment you most need help. Smaller signs matter too. Does the developer explain things in plain English, or hide behind jargon? Do they answer questions promptly? The way someone handles a quote is often the way they will handle the project.

It helps to compare quotes properly, rather than just picking the lowest number. Put them side by side and check the same things. What features are included? What is left out? How long will it take? What is the payment schedule? What happens after launch? Who owns the work? When you compare like with like, the real value becomes clear. The cheapest quote is rarely the cheapest project.

A useful habit is to ask each developer the same few questions. What would you leave out of version one, and why? What is the biggest risk in this project? What could make the price go up? What do you need from me, and by when? The answers will tell you a lot about how they think. It is also worth asking who will actually do the work, and how you will be kept updated. A short weekly update keeps a project on track. Silence is where projects drift.

Some business owners worry about asking too many questions. Do not. A good developer expects questions and welcomes them. The quote stage is the cheapest time to find problems. Fixing a misunderstanding before work starts costs nothing. Fixing it halfway through costs time and money.

When a quote feels right, it is based on a clear brief. It lists what is included and what is not. It breaks the work into stages with honest timing. It explains payment, testing, ownership, and support. And the developer behind it answers questions plainly and on time. That kind of quote may not be the cheapest, but it is the one most likely to deliver what was promised.

A team that quotes this way tends to work this way too. For example, TechCore Studio (https://techcorestudio.com) sets out each project in stages, with the features, timing, and after-launch support written down before work begins, so the business owner knows what to expect at each step.

A software quote is the first test of a working relationship. If it is clear, honest, and complete, the project has a good chance of going well. If it is vague, rushed, or too good to be true, trust that feeling. Take your time, ask the questions, and compare properly. The right developer will be glad you asked.

The 7-Second Rule: What Visitors Decide About Your Website Before They Read a Word

Anne Marcus — Fri, 13 Nov 2026 16:26:10 +0000

A visitor lands on your website. They do not read it. Not at first. In the first few seconds, they look at it. They take in the colours, the layout, the main image, and the first heading. Then they make a decision. Stay, or leave. Research into how people use the web has shown again and again that this decision happens fast, often within about seven seconds. Seven seconds is not much time. It is about as long as it takes to read this paragraph out loud. And yet it is enough for a visitor to decide whether your business looks trustworthy, professional, and worth their time.

The first thing a visitor judges is whether the site looks like it belongs to a real, current business. A design that looks ten years old sends a message, whether the owner means it to or not. It suggests the business may not be keeping up, or may not be paying attention. A site that looks clean and current suggests the opposite. It does not need to be flashy or expensive. It needs to look cared for. Clean spacing, readable text, photos that are in focus, and a layout that is not crowded. These are small things, but they add up to a feeling, and that feeling forms before a single word is read.

The second judgement happens just as fast. Can I find what I need here? A visitor arrives with a question in mind. They want to know what you do, how much it costs, where you are, or how to get in touch. If the answer is not obvious within seconds, they will look elsewhere. That is why the top of the homepage matters more than any other part of the site. It should say, in plain words, what the business does and who it is for. Not a clever slogan. Not a vague promise. A clear sentence. A visitor should not have to work out what the business sells. If they have to guess, they will guess wrong or give up.

Speed is part of the first impression too. A site that takes a long time to load feels broken, even if it is not. People are used to pages appearing almost instantly, and they have little patience for a spinning wheel. Large photos are the usual cause. A homepage full of huge images will look good on the designer's screen and load slowly on a customer's phone. Every second of delay loses visitors. The fix is practical rather than technical. Use smaller images, keep the homepage simple, and avoid anything that has to load before the visitor can see the page. A fast site feels professional. A slow one feels neglected.

The mobile view deserves special attention, because that is how most visitors arrive. A site that looks fine on a desktop computer can be a mess on a phone. Text too small to read, buttons too close together to tap, menus that are hard to open, and images that push the content sideways. Visitors will not pinch and zoom and struggle. They will leave. Every business owner should open their own website on a phone at least once a month and try to use it like a customer. Find the phone number. Fill in the contact form. Read the services page. If any of that is awkward, it needs fixing.

Trust signals are the next thing a visitor picks up on, even if they do not realise it. A real address, a real phone number, and a real email address make a business feel solid. Photos of real people and real work make it feel honest. Reviews from real customers, shown with names, make it feel proven. A site with no contact details, no photos, and no sign of real people behind it feels risky, even if the business is perfectly genuine. These details do not need to be fancy. They just need to be visible early, ideally on the homepage, where a visitor can see them without digging.

Clarity beats cleverness every time. A homepage that tries to be witty or artistic can be enjoyable, but it can also confuse. If a visitor has to think about what a heading means, the site has already lost a few of its precious seconds. Plain words win. Say what you do. Say who it is for. Say what to do next. A clear button that says Get a Quote or Book a Call is worth more than a clever phrase that nobody understands. Visitors are not judging your creativity. They are judging whether you can help them, and they want the answer quickly.

There is one more judgement that happens in those first seconds, and it is about focus. A homepage that tries to say everything at once says nothing. Too many messages, too many images, too many buttons, and the visitor does not know where to look. A focused homepage picks one main message and one main action, and lets everything else support them. The other services and details can live on their own pages, where interested visitors will find them. The homepage is the front door, not the whole shop.

The good news is that none of this requires a big budget or a complete rebuild. Most websites can be improved in a few hours by fixing the top of the homepage, simplifying the message, speeding up the images, and making sure the mobile view works. The best way to test it is to ask someone who has never seen the site to look at it for seven seconds, then close it and tell you what the business does and whether they would trust it. Their answer will tell you exactly what to fix.

Seven seconds is not long, but it is enough. It is enough for a visitor to feel that a business is professional, current, and worth a closer look. Or it is enough for them to leave and try the next result. The businesses that win those seven seconds are the ones that keep their homepage clear, fast, honest, and focused on the visitor. For owners who want a second pair of eyes on their own site, a design studio can review it and point out what a first-time visitor actually sees. DezignLoop (https://dezignloop.com) looks at small business websites with exactly that fresh eye, and helps owners make the first seven seconds count.

How to Find a Developer You Can Actually Trust

Anne Marcus — Thu, 12 Nov 2026 17:27:25 +0000

Hiring a developer is one of the highest-stakes decisions a small business owner makes. Get it right and you gain a tool that saves hours every week and opens up new revenue. Get it wrong and you can lose a year, a five-figure sum, and a lot of sleep before you admit it is not working.

The hard part is that most business owners are hiring for a skill they do not have themselves. You cannot judge code the way you would judge a plumber's work or a designer's portfolio. So how do you pick someone trustworthy when you cannot check the work directly?

Here is what actually works.

Start with the problem, not the person

Before you talk to anyone, write down what you need in plain language. Not "we need a React developer" but "our customers need to book online, pay a deposit, and get a reminder the day before, and our team needs to see the day's bookings on one screen."

That one paragraph does more than any job description. It lets good developers respond with a plan, and it exposes the ones who just say yes to everything. It also protects you from hiring someone whose skills do not match the job, because you have described the job in terms of outcomes, not technologies.

If you cannot describe the outcome clearly, that is fine too, but it means you need someone who will help you work it out before writing code. Say so upfront.

Freelancer, agency, or in-house?

There are three ways to get software built, and each suits a different situation.

A freelancer is usually the cheapest option and you talk directly to the person doing the work. That works well for a focused job with a clear scope. The risk is that one person covers design, code, testing, and hosting, and if they get busy or ill, the project stops. For a small, well-defined build, a good freelancer is hard to beat.

An agency brings a team. A project manager, designers, developers, and testers. You pay more, and you get continuity, a process, and someone to call when things go wrong. For bigger builds, for apps on both iPhone and Android, and for projects with a fixed deadline, an agency is usually the safer bet.

Hiring in-house only makes sense when software is core to your business and you have a steady year-long backlog of real work. A mid-level developer in the US costs roughly $120,000 to $180,000 a year all-in once you count salary, benefits, recruitment, and equipment. Most small businesses do not have enough continuous work to justify that, and an in-house hire with nothing to do is expensive in a different way.

For most first builds, the real choice is between a freelancer and a small agency. The rest of this guide applies to both.

The questions that actually tell you something

Forget the technical interview. You are not hiring for a coding exam. Ask questions that reveal how they work.

"Show me something you built for a business like mine." Then look at it properly. Does it work? Is it fast? Does it look like something a real customer would use? Ask what their role was and what happened after launch. A developer who can talk about the business result, not just the code, is a good sign.

"How do you handle it when a project goes wrong?" Every developer has a story here. The honest ones tell you about a project that ran late or a feature that failed, and what they did about it. The ones who say nothing ever goes wrong are either inexperienced or not being straight with you.

"Who owns the code?" This should be a short answer: you do. Get it in writing. The same goes for your data, your logins, and your app store accounts. If ownership is vague, that is a red flag.

"How do we communicate, and how often?" You want a regular rhythm, not silence for six weeks followed by a surprise delivery. Weekly updates, a shared list of what is done and what is next, and a direct way to reach them. That is the minimum.

"Who fixes things after launch, and what does it cost?" Software always needs care after launch. If the answer is a shrug, you will be on your own when something breaks on a Friday night.

The red flags

Some warning signs are worth taking seriously.

A quote that arrives suspiciously fast, after one short call, with a single round number and no breakdown. Nobody can price a real project that quickly. That quote is a guess with a margin built in, or it leaves things out that will appear as extras later.

A developer who says yes to every feature and every deadline without asking a single hard question. Good developers push back. They ask what can wait, what is risky, and what the budget really allows. If there is no pushback, there is no thinking.

No references, no live work to look at, and no willingness to let you speak to a past client. One bad reference is a warning. No references at all is a bigger one.

And the biggest red flag of all: pressure to pay a large sum upfront before any work is agreed in writing. A deposit is normal. A full payment before a single screen is designed is not.

How to structure the deal

Keep it simple and in writing. A short agreement that covers what is being built, what it costs, when it is due, who owns what, and what happens after launch will save you more trouble than any contract clause ever written.

Pay in stages tied to things you can see. A deposit to start, a payment when the design is approved, a payment when a working version is in your hands, and the final payment when the agreed version is live. Never pay everything upfront, and never accept a deal where the final payment comes before you have tested the result yourself.

Ask for a working version early, even if it is rough. The best protection against a bad outcome is seeing real progress in the first few weeks. If a developer cannot show you anything working after a month, something is wrong, and it is better to know that early.

The bottom line

You do not need to learn to code to hire a good developer. You need a clear description of what you want, a few honest conversations, and the discipline to check ownership, communication, and aftercare before you sign anything.

Talk to two or three people. Compare their questions, not just their prices. The one who asks the best questions about your business is usually the one who will build the best software for it.

If you would rather talk to a team that starts with your business and works backwards to the technology, TechCore Studio works that way. We will tell you honestly if your job is a fit for us or if someone else would serve you better.

Your App Is Built. Now Get It Into the App Stores Without the Headache

Anne Marcus — Thu, 12 Nov 2026 16:59:36 +0000

You built the app. It works, your team has tested it, and a few friendly customers have tried it and liked it. Now comes the part nobody warned you about: getting it into the Apple App Store and Google Play.

For first-time app owners, this stage is often a surprise. The stores have rules, review processes, and rejection letters, and they do not care how good your app is if the paperwork is wrong. This guide walks through the whole thing in plain language, so you can launch without the usual delays.

Start with the accounts, not the app

Before anything is submitted, you need developer accounts, and they take time to set up, so do this early.

Apple charges $99 a year for a developer account. Google Play charges a one-off $25. Those are the official fees, and you pay them directly to Apple and Google, not to your developer.

Set the accounts up in your business name, with your business email, and make sure you own them. This matters more than people realise. If your developer sets the account up under their name and then disappears, getting your app back is painful. Own the accounts from day one, and give your developer access to upload on your behalf.

Apple will ask you to verify your business. That can take a few days, sometimes longer, so do not leave it until launch week. Have your business details and a phone number ready, and check the verification email promptly.

What the stores actually check

Both stores review every app before it goes live, and both can reject it. Apple is stricter and slower, usually a day or two for review, sometimes longer. Google is generally faster, often within hours, but it still checks.

Here is what they look at. Does the app work, or does it crash? Does it do what the description says it does? Does it ask for permissions it does not need? Does it handle user data properly, with a privacy policy that says what is collected and why? Does it follow the rules on payments, especially on Apple, where digital purchases usually have to go through Apple's own system?

A common reason for rejection is an app that looks unfinished or is too thin. Apple has a rule against apps that are just a website wrapped in a shell, with no real app features. If your app is basically a web page, expect a rejection and a request to add proper app functionality.

Another common one is missing information. No privacy policy link, no contact details, no demo account for the reviewer to log in with. The reviewer needs to see the app working. If they cannot log in, they cannot approve it. Always include a demo login in the submission notes.

The listing matters more than you think

Your store listing is your shop window, and most app owners treat it as an afterthought. That is a mistake. The listing decides whether someone downloads your app or scrolls past it.

The name should be clear. People search for what the app does, not for your brand name. If your app helps people book a cleaner, the name should say that. You can include your brand, but the function comes first.

The description should answer three questions in the first few lines. What does the app do, who is it for, and why is it worth downloading? Most people never read past the first paragraph, so put the best part at the top. Keep it honest. Do not promise features that are not there yet.

Screenshots are the most powerful part of the listing. Use real screens from the app, and add short text on each one explaining what the user is looking at. Show the app doing its best work. A screenshot of a login screen tells nobody anything. A screenshot of a booking being confirmed in two taps tells the whole story.

Keywords matter too. On Apple, you get a small field for search keywords, so use words your customers would actually type. On Google Play, the description itself is searchable, so write it in natural language that includes the words people search for.

The launch checklist

Here is a practical checklist to run through before you hit submit.

Your accounts are set up in your business name, and you own them. Your privacy policy is written, published on your website, and linked in the listing. The app has been tested on real phones, not just in a simulator, on both the newest and slightly older models. You have a demo account for the reviewer, with the login details in the submission notes. Your screenshots show the app at its best, with short captions. Your description is honest and the first paragraph sells the main benefit. You have checked that every link in the app works, including the support email and the website. And you have a plan for the first week, someone watching for crashes, answering reviews, and fixing problems fast.

Run through that list twice. Most launch delays come from one item on it being missed.

What to do when you get rejected

Rejection is normal. Plenty of good apps get rejected the first time, usually for something small. Do not panic and do not argue.

Read the rejection message carefully. It will usually point to a specific rule and tell you what to fix. Fix exactly that, write a short note explaining what changed, and resubmit. Most rejections are cleared on the second attempt.

If the message is vague, ask for clarification through the review system. Reviewers do respond, and a polite, specific question gets a useful answer.

After launch, the work is not over

Getting into the stores is the start, not the finish. The first week tells you a lot. Watch for crash reports, read every review, and answer the ones that raise a real issue. Early reviews carry weight, and a fast, helpful reply to a problem turns an unhappy user into a loyal one.

Keep a list of what users ask for. The first update should fix the small things people trip over, not add big new features.

And plan your updates. Apple and Google both change their requirements regularly. An app that is not updated for a year can stop working or get removed. Budget for regular maintenance, and treat it as part of the cost of having an app, not as an optional extra.

The bottom line

Launching an app is mostly admin, done carefully. Own your accounts, give the reviewer everything they need, write a listing that sells the benefit in the first few lines, and test on real phones before you submit. Do that, and the stores are a smooth final step rather than a frustrating delay.

If you would like a hand with the launch, or with building the app in the first place, TechCore Studio handles the whole process, from the first screen to the day it goes live in both stores.