Direct answer
Before a software project starts, gather real examples of the data the software will handle: current spreadsheets and system exports, a small sample that includes both tidy and messy records, the documents and forms that come in, and the name of the person who understands the data's oddities. Note what you know is wrong and leave it as it is for now. A builder who has seen your data can size the work, design the data model and write import rules and test cases from facts. One who has only heard a description has to guess. Where the project involves moving existing records, this feeds directly into the spreadsheet to database migration or the legacy system data migration plan.
What to export
Export what people work from today, in the form they see it, not a cleaned-up version:
- Current spreadsheets, including the hidden or side tabs people rely on
- Exports from the CRM or other systems that hold the data
- Samples of the reports people read and rely on
- Field lists or screenshots where an export is not possible
A sample set with clean records, messy records and a duplicate
A sample made only of your best records misleads the builder. Include some typical ones, some that are awkward, some with missing fields, and at least one pair that you know are duplicates. The messy ones show what the software must tolerate, and the duplicate shows the rule you actually apply today when you decide that two records are the same person or order. Say which rows are which.
The documents and forms that come in
Data does not only live in tables. Collect examples of the invoices, orders, enquiry emails, forms and forwarded files that enter your process, since those show what information really arrives and in what shape. If there are several versions or senders, include one of each. For automation projects, the AI intake data checklist shows how the same material is used.
What to mask or remove before sharing
Real samples often contain personal or commercial information that does not need to leave your company to be useful. Decide what can be replaced with made-up values that keep the same shape, and what should be removed. Check the rules with whoever owns data protection in your company before sending anything. This page gives no legal or compliance advice, and it does not claim that masking makes data anonymous.
Name the person who knows the data's quirks
Every dataset has habits that only one person knows: a column that means something different since last year, a code used for a special customer, a field people abuse for notes. Name that person, and make sure they are available to answer the builder's questions. It is often worth more than any document.
Known problems, written down
List what you already know is wrong: duplicates, missing fields, old codes that are no longer used, values that differ by spelling. It saves the builder from being surprised and from treating each problem as a discovery. The data formats before migration checklist lists format problems worth naming too.
What not to fix yet
Resist cleaning everything before the project starts. Tidying the data in advance removes exactly the evidence the builder needs, and you may clean things the new system would have handled differently. Fix only what blocks sharing, such as sensitive details, and leave the rest as it is with a note describing it.
How the builder uses it
With samples in hand, the builder can design the data model around real fields, write import rules that expect the real mess, prepare test cases with realistic records and estimate the work with fewer unknowns. Keep the samples together with a short note of where each came from and when.
Where LATYNEX fits
LATYNEX reads the samples during scoping and uses them to define the data model, the import rules and the test cases in the written scope. See Web Application Development.
When LATYNEX is not the right fit
If no data exists yet because the process itself is new, there is nothing to prepare, and the better starting point is the MVP scope guide. This page also does not claim that all existing data can be migrated, and it does not replace advice from whoever handles data protection at your company.
Questions
What data should I prepare before a software project?+
Current exports and spreadsheets, a sample with clean and messy records, examples of incoming documents and forms, and the name of the person who understands the data.
Should I clean the data first?+
No. Leave it as it is and write down the known problems. Cleaning in advance removes the evidence the builder needs to design around.
Can I share real customer data with a developer?+
Check with whoever owns data protection at your company first. Often, made-up values with the same shape are enough for scoping.
Why include a duplicate in the sample?+
It shows the rule you actually use to decide that two records are the same, which the software then has to follow.
What if we have no data yet?+
Then the process is new, and it is better to define the smallest useful first version. See the MVP scope guide.